<%BANNER%>

A Programming Model for Safer Pervasive Spaces

Permanent Link: http://ufdc.ufl.edu/UFE0044981/00001

Material Information

Title: A Programming Model for Safer Pervasive Spaces
Physical Description: 1 online resource (182 p.)
Language: english
Creator: Chen, Chao
Publisher: University of Florida
Place of Publication: Gainesville, Fla.
Publication Date: 2012

Subjects

Subjects / Keywords: safety
Computer and Information Science and Engineering -- Dissertations, Academic -- UF
Genre: Computer Engineering thesis, Ph.D.
bibliography   ( marcgt )
theses   ( marcgt )
government publication (state, provincial, terriorial, dependent)   ( marcgt )
born-digital   ( sobekcm )
Electronic Thesis or Dissertation

Notes

Abstract: In a world where pervasive computing technology permeates every corner of our lives, safety is paramount. Unlike traditional computer systems, pervasive systems tie intimately with the users. Errors and conflicts in such space could have detrimental, dangerous or undesired effects on thespace, 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 de jour, which is inadequate. A programming model is needed to encourage and obligate various roles engaged in the development of pervasive spaces to contribute to increasing safety.  This research presents a programming model that utilizes role-specific safety knowledge, and takes advantage of the rich sensing and actuation capabilities of pervasive systems to prevent or detect/avert“impermissible contexts”. A domain-independent ontology for safety (DiOS) is presented, which provides a uniform semantic basis for representation of safety knowledge and concerns. We follow by introducing DDL, a practice to augment a device description language with DiOS vocabulary. We show how DDL/DiOS enablesa path to integrate domain-specific safety knowledge using a universal semantic framework.   Our proposed programming model also attempts to bring the well-established concept of transaction to the realm of pervasive computing. We propose pervasive transaction, a novel concept that serves as an abstraction of the cyber-physical interactions in pervasive space. We further identify a set of properties: atomicity,integrity, isolation and durability (known as AI2D-safety properties), which together define the safety criteria for runtime pervasive transaction behavior. The concepts of pervasive transaction and AI2D safety reveal a path to improve the overall safety of pervasive spaces through transaction management - safety risks can be prevented, or detected/mitigatedby regulating the runtime behavior of pervasive transactions. As an implementation of such runtime mechanism, we present the context lock protocol,which introduces a number of relaxations to suit the practical need ofpervasive transactions. We prove the correctness of the protocol by showing it always produces transaction histories that satisfy the AI2D-safety criteria. We conclude this work with an analytical model that evaluates the performance of the context lock protocol. We present the model derivation and numerical results.
General Note: In the series University of Florida Digital Collections.
General Note: Includes vita.
Bibliography: Includes bibliographical references.
Source of Description: Description based on online resource; title from PDF title page.
Source of Description: This bibliographic record is available under the Creative Commons CC0 public domain dedication. The University of Florida Libraries, as creator of this bibliographic record, has waived all rights to it worldwide under copyright law, including all related and neighboring rights, to the extent allowed by law.
Statement of Responsibility: by Chao Chen.
Thesis: Thesis (Ph.D.)--University of Florida, 2012.
Local: Adviser: Helal, Abdelsalam A.

Record Information

Source Institution: UFRGP
Rights Management: Applicable rights reserved.
Classification: lcc - LD1780 2012
System ID: UFE0044981:00001

Permanent Link: http://ufdc.ufl.edu/UFE0044981/00001

Material Information

Title: A Programming Model for Safer Pervasive Spaces
Physical Description: 1 online resource (182 p.)
Language: english
Creator: Chen, Chao
Publisher: University of Florida
Place of Publication: Gainesville, Fla.
Publication Date: 2012

Subjects

Subjects / Keywords: safety
Computer and Information Science and Engineering -- Dissertations, Academic -- UF
Genre: Computer Engineering thesis, Ph.D.
bibliography   ( marcgt )
theses   ( marcgt )
government publication (state, provincial, terriorial, dependent)   ( marcgt )
born-digital   ( sobekcm )
Electronic Thesis or Dissertation

Notes

Abstract: In a world where pervasive computing technology permeates every corner of our lives, safety is paramount. Unlike traditional computer systems, pervasive systems tie intimately with the users. Errors and conflicts in such space could have detrimental, dangerous or undesired effects on thespace, 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 de jour, which is inadequate. A programming model is needed to encourage and obligate various roles engaged in the development of pervasive spaces to contribute to increasing safety.  This research presents a programming model that utilizes role-specific safety knowledge, and takes advantage of the rich sensing and actuation capabilities of pervasive systems to prevent or detect/avert“impermissible contexts”. A domain-independent ontology for safety (DiOS) is presented, which provides a uniform semantic basis for representation of safety knowledge and concerns. We follow by introducing DDL, a practice to augment a device description language with DiOS vocabulary. We show how DDL/DiOS enablesa path to integrate domain-specific safety knowledge using a universal semantic framework.   Our proposed programming model also attempts to bring the well-established concept of transaction to the realm of pervasive computing. We propose pervasive transaction, a novel concept that serves as an abstraction of the cyber-physical interactions in pervasive space. We further identify a set of properties: atomicity,integrity, isolation and durability (known as AI2D-safety properties), which together define the safety criteria for runtime pervasive transaction behavior. The concepts of pervasive transaction and AI2D safety reveal a path to improve the overall safety of pervasive spaces through transaction management - safety risks can be prevented, or detected/mitigatedby regulating the runtime behavior of pervasive transactions. As an implementation of such runtime mechanism, we present the context lock protocol,which introduces a number of relaxations to suit the practical need ofpervasive transactions. We prove the correctness of the protocol by showing it always produces transaction histories that satisfy the AI2D-safety criteria. We conclude this work with an analytical model that evaluates the performance of the context lock protocol. We present the model derivation and numerical results.
General Note: In the series University of Florida Digital Collections.
General Note: Includes vita.
Bibliography: Includes bibliographical references.
Source of Description: Description based on online resource; title from PDF title page.
Source of Description: This bibliographic record is available under the Creative Commons CC0 public domain dedication. The University of Florida Libraries, as creator of this bibliographic record, has waived all rights to it worldwide under copyright law, including all related and neighboring rights, to the extent allowed by law.
Statement of Responsibility: by Chao Chen.
Thesis: Thesis (Ph.D.)--University of Florida, 2012.
Local: Adviser: Helal, Abdelsalam A.

Record Information

Source Institution: UFRGP
Rights Management: Applicable rights reserved.
Classification: lcc - LD1780 2012
System ID: UFE0044981:00001


This item has the following downloads:


Full Text

PAGE 1

1 A PROGRAMMING MODEL FOR SAFER PERVASIVE SPACES By CHAO CHEN A DISSERTATION PRESENTED TO THE GRADUATE SCHOOL OF THE UNIVERSITY OF FLORIDA IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE DEGREE OF DOCTOR OF PHILOSOPHY UNIVER SITY OF FLORIDA 2012

PAGE 2

2 2012 Chao Chen

PAGE 3

3 To my Mom

PAGE 4

4 ACKNOWLEDGMENTS I would like to express the deepest gratitude to my committee chair, Professor Sumi Helal, who has been patiently advising me and persistently helping me in the past several years. Without his guidance, caring, and patience, this dissertation would not have been possible I also would like to thank my committee members, Professor Shigang Chen, Professor Paul Fishwick, Professor My T. Thai, and Professor Raymond Issa, for their guidance and constructive comments during the course of this dissertation research. In addition, I give my thanks to all colleagues in the Mobile and Pervasive Computing lab. Special thanks to Duckki Lee, who as a good friend, is always willing to help an d offer his best suggestions. Finally, I would like to thank my families. My parents, Su Liu and Zhigang Chen, and my wife, Hui Zhou, were always standing by me and giving unconditional support and love.

PAGE 5

5 TABLE OF CONTENTS page ACKNOWLEDGMENTS ................................ ................................ ................................ .. 4 LIST OF TABLES ................................ ................................ ................................ ............ 9 LIST OF FIGURES ................................ ................................ ................................ ........ 10 LI ST OF ABBREVIATIONS ................................ ................................ ........................... 12 ABSTRACT ................................ ................................ ................................ ................... 13 CHAPTER 1 PROBLEM STATEMENT ................................ ................................ ........................ 15 Introduction ................................ ................................ ................................ ............. 15 Fusion Of The Cyber And Physical Worlds ................................ ...................... 15 Invisible Technology ................................ ................................ ......................... 16 User centric Computing ................................ ................................ .................... 16 Unleashing the Programming Power of Pervasive Computing ............................... 17 Safety Issues in Perva sive Spaces ................................ ................................ ......... 19 Scenario A Over frequent Actuation ................................ ............................... 19 Scenario B Hardware Failure ................................ ................................ ........ 19 Scenario C Service Conflict ................................ ................................ ........... 20 Scenario D Changing Requirements ................................ ............................. 20 Programming Models for Pervasive Spaces ................................ ........................... 21 Scope ................................ ................................ ................................ ...................... 23 2 LITERATURE REVIEW ................................ ................................ .......................... 26 Introduction ................................ ................................ ................................ ............. 26 Safety Engineering in Conventional Industries ................................ ....................... 27 Commercial Aviation ................................ ................................ ........................ 28 Rail Transportation ................................ ................................ ........................... 28 Chemical Processing ................................ ................................ ........................ 28 Safety vs. Reliability ................................ ................................ ......................... 29 Pervasive Space Engineering vs. Product Line Engineering ............................ 30 Research on Safety and Safety related Issues in Pervasive Computing ................ 30 Research on Safety related Issues ................................ ................................ .. 30 Safety Research in Pervasive Computing ................................ ........................ 32 3 PROBLEM ANALYSIS ................................ ................................ ............................ 35 Fundamental Elements of Pervasive Spaces ................................ ......................... 35 Device ................................ ................................ ................................ .............. 36

PAGE 6

6 Service ................................ ................................ ................................ ............. 36 User ................................ ................................ ................................ .................. 37 Space ................................ ................................ ................................ ............... 37 Roles and Collaboration Models for the Design, Creation, and Management of Pervasive Spaces ................................ ................................ ................................ 38 General Space Developer ................................ ................................ ................ 42 Space Admin ................................ ................................ ................................ .... 42 Space Technician ................................ ................................ ............................. 43 Device Manufacture ................................ ................................ ......................... 43 Middleware Provider ................................ ................................ ......................... 44 Space Service Provider ................................ ................................ .................... 44 4 OVERALL APPROACH ................................ ................................ .......................... 49 Why do We Need an Overall Approach? ................................ ................................ 49 Challenges ................................ ................................ ................................ .............. 50 The Approach ................................ ................................ ................................ ......... 50 A Domain independent Ontology for Safety ................................ ..................... 51 Pervasive Transaction ................................ ................................ ...................... 52 The Scope ................................ ................................ ................................ .............. 53 5 DiOS: A DOMAIN INDEPENDENT ONTOLOGY FOR S AFETY ............................ 56 DiOS Core ................................ ................................ ................................ .............. 56 Safety Classification ................................ ................................ ......................... 57 Context Compositi on ................................ ................................ ........................ 59 DiOS Periphery ................................ ................................ ................................ ....... 60 Physical Space ................................ ................................ ................................ 61 User ................................ ................................ ................................ .................. 61 Service ................................ ................................ ................................ ............. 62 Device Service ................................ ................................ ................................ 62 Summary ................................ ................................ ................................ ................ 63 6 DDL: UTILIZING DEVICE INFORMATION FOR SAFER PERVASIVE SPACES ... 65 Introduction ................................ ................................ ................................ ............. 65 Introducing DDL: the Device Description Language ................................ ............... 67 Expressing Safety Knowledge and Concerns ................................ ......................... 68 Context Constraint ................................ ................................ ............................ 70 Conflict List ................................ ................................ ................................ ....... 71 Fail safe Method ................................ ................................ ............................... 71 Engaging Devices in Risk Mitigation ................................ ................................ ....... 73 Devices: a Context Based View ................................ ................................ ....... 73 DoST: a Domain Ontology for Sensor Taxonomy ................................ ............ 74 Su mmary ................................ ................................ ................................ ................ 76 7 FORMALIZING SAFETY IN PERVASIVE SPACES ................................ ............... 79

PAGE 7

7 Motivation ................................ ................................ ................................ ............... 79 Revisiting ACID properties for Pervasive Systems ................................ ................. 81 Atomicity ................................ ................................ ................................ ........... 82 Consistency ................................ ................................ ................................ ...... 82 Isolation ................................ ................................ ................................ ............ 83 Durability ................................ ................................ ................................ .......... 83 Context, Context Entities, and Context Envelope ................................ ................... 84 Context and Context Entities ................................ ................................ ............ 84 Context Envelope ................................ ................................ ............................. 86 Sensing and Actuations ................................ ................................ .......................... 88 Pervasive Transactions ................................ ................................ ........................... 90 AI 2 D safety ................................ ................................ ................................ .............. 93 AI 2 D Properties ................................ ................................ ................................ 93 Define Safety Using AI 2 D Properties ................................ ................................ 94 8 PERVASIVE TRANSACTION IMPLEMENTATION ................................ ................ 97 Intr oduction ................................ ................................ ................................ ............. 97 Pervasive Transaction Model ................................ ................................ .................. 98 Pervasive Transaction Overview ................................ ................................ ...... 98 Pervasive Transaction Lifecycle ................................ ................................ ....... 98 Pervasive Transaction Operations ................................ ................................ 101 Pervasive Transaction Use Cases ................................ ................................ 106 Pervasive Transaction Programming Interface ................................ ............... 110 The Context Lock Protocol ................................ ................................ .................... 111 Pervasive Isolation Semantics ................................ ................................ ........ 111 Context Lock Types ................................ ................................ ........................ 115 The Protocol ................................ ................................ ................................ ... 118 Proof of Correctness ................................ ................................ ...................... 119 Correctness of H 1 ................................ ................................ ..................... 120 Correctness of H 2 ................................ ................................ ..................... 122 Pervasive Transaction Management Architecture ................................ ................ 123 Architecture Overview ................................ ................................ .................... 123 Transaction Pool ................................ ................................ ............................ 123 Transaction Processor ................................ ................................ .................... 125 Context Lock Manager ................................ ................................ ................... 126 Context Map ................................ ................................ ................................ ... 127 Safety Transaction Mechanism ................................ ................................ ............. 127 Revisiting Actuators ................................ ................................ ........................ 128 Problem Form ulation ................................ ................................ ...................... 129 Algorithm A. Composing safety transaction using logical operations ....... 129 Algorithm B. Translating from logical to logi cal operations ....................... 130 Limitations of Safety Transactions ................................ ................................ .. 131 9 PERFORMANCE EVALUATION ................................ ................................ .......... 139 Approach ................................ ................................ ................................ .............. 139

PAGE 8

8 Analysis 1 Free, and Analysis ................................ ................................ ...... 139 Objective ................................ ................................ ................................ ........ 139 Transaction Model ................................ ................................ .......................... 140 Lock Holding Time ................................ ................................ .......................... 140 Probability of Read or Write ................................ ................................ ............ 141 Probability of Contention. ................................ ................................ ............... 142 Uniform based Derivation of and ................................ ................... 142 Gaussian based Derivation of and ................................ ................ 143 Probability to Abort. ................................ ................................ ........................ 144 Mean Transaction Lifetime ................................ ................................ ............. 145 Revisiting Lock Holding Time ................................ ................................ ......... 145 Numerical Resolution ................................ ................................ ..................... 146 Results ................................ ................................ ................................ ........... 146 Analysis 2 and Analysis ................................ ................................ ............... 148 Objective ................................ ................................ ................................ ........ 148 Probability of a Write Success ................................ ................................ ........ 148 Probability of Completion ................................ ................................ ........ 149 Mean Time to Completion ................................ ..................... 149 Probability of Durability ................................ ................................ ........... 150 Updating Transaction Model with and ................................ ...................... 150 Results ................................ ................................ ................................ ........... 151 10 CONCLUSION ................................ ................................ ................................ ...... 158 APPENDIX A DDL DATA MODELS ................................ ................................ ............................ 160 B XML SCHEMA FOR DDL ................................ ................................ ..................... 162 C SAMPLE DDL DOCUMENT FOR TMP36 ANALOG TEMPERATURE SENSOR 170 D DATA STRUCTURE DESIGN FOR PERVASIVE TRANSACTION PROCESSOR ................................ ................................ ................................ ....... 173 LIST OF REFERENCES ................................ ................................ ............................. 176 BIOGRAPHICAL SKETCH ................................ ................................ .......................... 182

PAGE 9

9 LIST OF TABLES Table page 2 1 Comparison between aircraft cockpit and smart home. ................................ ...... 34 3 1 Distribution of resources/responsibilities among roles ................................ ........ 46 8 1 State transition rules of pervasive transaction processing ................................ 132 8 2 Compatibility Matrix of Operations. ................................ ................................ ... 132 9 1 Input Configurations ................................ ................................ ......................... 153 A 1 Symbols notations for element occurrences. ................................ .................... 160

PAGE 10

10 LIST OF FIGURES Figure page 1 1 Tradeoff between safety and expressiveness of programming models in pervasive spaces. ................................ ................................ ............................... 25 3 1 Define a safe pervasive space element wise. The set of safe states of a pervasive space is the intersection of the safe states of each element in this space including device, service, user and the space itself. ................................ 47 3 2 Overview of the m ultiple role collaboration model in pervasive space development and management. ................................ ................................ ......... 48 4 1 Overview of safety architecture for pervasive spaces, which is divided into system wide (left) and progra m wide (right) safety support. ............................... 55 5 1 Overview of the DiOS ontology. ................................ ................................ .......... 64 6 1 TMD5510FX01 ambient light sensor and its DDL snippet s. (The snippets define the sensor support operating temperatures from 40 C to +100 C.) ...... 77 6 2 Type 3374 31 electric linear actuator and its DDL snippets. (The snippets define the fail safe ................................ ......... 77 6 3 A Snippet of the DoST ontology. ................................ ................................ ........ 78 7 1 The concept of context entity enpowers a new perspective of sensor actuator relations in pervasive spaces. ................................ ................................ ............. 95 7 2 Visualization of context envelopes in 3 Dimensional (Fig. 7 2.a) and n Dimensional (Fig. 7 2.b) context spaces. ................................ ........................... 95 7 3 The tunnel view of context envelopes. ................................ ............................... 96 8 1 The state diagram of a pervasive transaction. ................................ .................. 133 8 2 Procedure of pre commit. ................................ ................................ ................. 134 8 3 Procedure of fail safe abort ( TR_ABORT ). ................................ ....................... 135 8 4 The Pervasive T ransaction Management Architecture ................................ ..... 136 8 5 Algorithm for composing safety transaction with logical operations. ................. 137 8 6 Algorithm for translating logical to physical operations. ................................ .... 137 8 7 Improved algorithm combining Procedure A and B. ................................ ......... 138

PAGE 11

11 9 1 Effect of Free Operations on the probability to abort We show under four different values for (mean distance to free). In this experiment, ................................ ................................ ................................ ...... 154 9 2 Effect of relaxation param eter on the probability to abort We show under four different values for In this experiment, ........... 154 9 3 Effect of relaxation parameter on the probability to abort We show under four different values for In this experiment, ........... 155 9 4 Effect of relaxation parameter on the probability to abort under a h igh write ratio. We show under four different values for In this experiment, ................................ ................................ .... 155 9 5 Compound effect of and We show under four different combin ations for ( ) values. In this experiment, ................. 156 9 6 Effect of on the probability to abort We show under four different values for In this experime nt, ................................ ................................ ................................ .......... 156 9 7 Effect of on the probability to abort We show under four different values for In this experiment, ................................ ................................ ................................ ........... 157 9 8 Compound effects of and on the probability to abort We show under four different combinations for ( ) values In this experiment, ................................ ................................ ............................ 157 A 1 The data model of the DDL root element. ................................ ......................... 161 A 2 DDL Data Model for Sensor. ................................ ................................ ............. 161 A 3 DDL Data Model for Device. ................................ ................................ ............. 161

PAGE 12

12 LIST OF ABBREVIATION S API Application programming interface DDL Device Description Language D I OS Domain independent Ontolo gy for Safety D O ST Domain ontology for Sensor Taxonomy GTSH Gator Tech Smart House HCI Human computer interface I O T Internet of Things OWL Web ontology language RDF Resource description framework RFID Radio frequency identification SOA Service oriented arc hitecture XML Extensible markup language

PAGE 13

13 Abstract of Dissertation Presented to the Graduate School of the University of Florida in Partial Fulfillment of the Requirements for the Degree of Doctor of Philosophy A PROGRAMMING MODEL FOR S AFER PERVASIVE SPACES By Chao Chen December 2012 Chair: Abdelsalam (Sumi) Helal Major: Computer Engineering In a world where pervasive computing technology permeates every corner of our lives, safety is paramount Unlike traditional computer systems, pervasive systems tie intimately with the users. 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 conscio us of the issue of safety. Unrestrained programming is the model de jour, which is inadequate. A programming model is needed to encourage and obligate various roles engaged in the development of pervasive spaces to contribute to increasing safety. This re search presents a programming model that utilizes role specific safety knowledge, and takes advantage of the rich sensing and actuation capabilities of independent ontology for safety (DiOS) is presented, which provides a uniform semantic basis for representation of safety knowledge and concerns. We follow by introducing DDL, a practice to augment a device description language with DiOS vocabulary. We show how DDL/DiOS enables a path to integrate domain specific safety knowledge using a universal semantic framework.

PAGE 14

14 Our proposed programming model also attempts to bring the well established concept of transaction to the realm of pervasive computing. We propose pervasive transa ction, a novel concept that serves as an abstraction of the cyber physical interactions in pervasive space We further identify a set of properties: atomicity, inte grity, isolation and durability (known as AI 2 D safety properties), which together define the safety criteria for runtime pervasive transaction behavior The concepts of pervasive transaction and AI 2 D safety reveal a path to improve the overall safety of pervasive spaces through transaction management safety risks can be prevented, or detected/m itigated by regulating the runtime behavior of pervasive transactions. As an implementation of such runtime mechanism, we present the context lock protocol which introduce s a number of relaxations to suit the practical need of pervasive tra nsactions. We p rove the correctness of the protocol by showing it always produces transaction histories that satisfy the AI 2 D safety criteria. We conclude this work with an analytical model that evaluate s the performance of the context lock protocol. We present the model derivation and numerical results.

PAGE 15

15 CHAPTER 1 PROBLEM STATEMENT Introduction The most profound technologies are those that disappear. They weave themselves into the fabric of everyday life until they are indistinguishable from it. Mark Weiser The C omputer for the 21st Century The essence of that vision was the creation of environments saturated with computing and communication capability, yet gracefully integrated with human users. M. Satyanarayanan Pervasive Computing: Vision and Challenges T he vision of pervasive computing, as described by Mark Weiser [22 ] in 1991, and elaborated by M. Satyanarayanan [23 ] in 2001, promised great opportunities to our future as individuals, societies and organizations. But these opportunities do not come withou t higher risks inherent in the nature of the highly instrumented spaces of deployment. The extensive interactions between technology and human, raises concerns over a number of issues, especially o n safety and human well being [3 ]. Without a thorough under standing of the safety implications of pervasive computing technology, it is too risky for this community to move beyond prototypes and trials in controlled environments and rush into large scale practical system deployments with actual impacts, based on b unveiled, there remains a need to revisit and reflect on what this vision entails. Fusion Of The Cyber And Physical Worlds The extensive interactions between the pervasive system and the physical world, enabled by the massive deployment and use of sensors and actuators, makes it possible for programmers to create pervasive applications that deliver convenient

PAGE 16

16 services and critical assistances in many aspects of our lives. However, the capability of a pervasive system to interact and influence the physical world also implies that the impact of malfunctioned systems or ill programmed applications is no longer limited to loss of data, waste of time and effort or a crash of a computer; the risk of vario us harmful ramifications to the users and damages to the physical properties are as real as those services the pervasive system intends to provide. Invisible Technology Pervasive computing technology is expected to fade into the background of our lives t o become calm and even invisible [4] While invisibility is a much desired merit when pervasive services are quietly and smoothly performing their daily duties, it creates a sense of lost control when a pervasive system disconnects itself from users under the circumstances of failures, hazards and other critical conditions. Without a proper channel of human computer interaction, the calmness of computing, in turn, may result in hectic reactions from its human users User centric Computing Many pervasive sy stems are intimate [5][6] because they have extensive interactions with users, and perform personal tasks on behalf of them. Intelligent environments such as smart homes and intelligent vehicles keep extensive records of their users and act upon their pre ferences and limitations. These systems exist in homes and cars, which are considered to be private, safe and treated with affections. Many services involve our daily routines, including medicine reminder, scheduler, or even personal hygiene. They are inte expectations and trust from users. The intimacy between human and pervasive systems

PAGE 17

17 magnifies the sense of frustration when these services fail to perform or even cause damages [ 3] The pervasive computing com munity has been spending great efforts to achieve remarkable progress on research issues such as device integration, service discovery, security and privacy. However, the issue of safety in pervasive spaces largely remains an unchart ed area [7][10] Most o f the residential spaces and work sites nowadays adopt some form o f safety codes and standards [8][9] In spite of the extensive deployment of pervasive infrastructures and devices, most of these spaces are still relying heavily on human consciousness and constant effort for compliance and enforcement of these safety protocols. Sensor technologies introduce great opportunities for monitoring and detecting critical conditions but have been put in limited use. Typical applications such as smoke detectors and burglary alarms are often packaged as closed systems by their vendors, and are therefore not programmable and hardly configurable to satisfy varying safety needs. While there is an imminent need in motes open and flexible compositions of sensors and actuators to provide extended and customizable safety services, existing programming models suffer from lack of checks and balances on programmers, which themselves may open greater loopholes that invite safety hazards and damages to the space [ 10]. Unleashing the Programming Power of Pervasive Computing As new sensing and actuation technology continue to emerge, possibilities for new pervasive computing applications are endless. Even conventional devices and appliances are being re purposed to serve completely non intended use. For example, compact fluorescent lights have been recently shown to be useful as sen sors to detect

PAGE 18

18 human presence [69 ]; and cellphone microphones have been creatively used as healt h sen sors to detect lung functions [72 ]. An infrastructure mediated sensing approach is therefore emerging which proposes to reuse existing infrastr uctures, such as HVAC systems [71 ], and conventional gas, waster or electricity meters to sens e events and h uman activities [70 ]. However, realizations of these ideas rely on one important pre requisite the pervasive systems need to be programmable. Devices, services, and infrastructures in general, should provide external accessibility through open interface s (APIs), to support and encourage composition and collaboration with others, and to enable novel and more sophisticated services. A programmable pervasive system, as the above examples promised, will no doubt improve utilization, foster better and more i nnovative applications, achieve enhanced user experience, improved quality of life, and increased return on investment. In reality though, we have been building spaces that were intentionally designed with limited programmability. Spaces have been instrume nted with separate systems, each working in isolation, to accomplish a fixed set of functions. Systems such as HVAC, gas and electricity meters, fire alarms, and security monitors are regarded as "stovepipes" closed, hardly evolving, and inaccessible. An important reason for such stovepipes is the concern of safety as systems becomes more open, new uncertainties will be introduced, which either creates new types of safety hazards, or impairs the existing critical services that these systems were designe d for. The goal of this research, therefore, is to unleash the potential of pervasive we aim to create a programming

PAGE 19

19 model for pervasive systems that encourages interactions and collaborations among servi ces, and at the same time addresses the safety concerns by enabling safety enforcement and assurance. In the remainder of this c hapter, we first take a closer look at the potential safety problems by presenting a few scenarios Then we survey the existing programming models and discuss why they are risk prone or inadequate to address safety problems. We conclude this chapter by defining the scope of this dissertation. Safet y Issues in Pervasive Spaces A typical pervasive space is a physical space instrume nted by a number of sensors and actuators, which are managed by a middleware and its software components, to provide a variety of services and assistances to users [37]. In addition to the common safety hazards [35][36] in mundane environments, pervasive s paces are often exposed to greater risks because of ill programmed software services or unreliable hardware components of pervasive systems [34]. In this section, we present a few scenarios to exemplify the issue of safety in pervasive spaces Scenario A Over frequent Actuation The smart entrance service is an abstraction of a door opener and provides a doorOpen() method. Everything looks solid until an excited programmer calls this method once every 5 seconds, only to find that the thin metal latch, whic h the service is truly representing, cannot withstand the repe ated fatigue and finally breaks Scenario B Hardware Failure e, and an actuator to open / close the door. When a visitor arrives, the service opens the door. However, the floor sensor runs out of

PAGE 20

20 service is suspended in the midd le, creating an unsecure situation by leaving the door open Scenario C Service Conflict The smart entrance service is modified to accommodate people with disabilities. It holds the door open for an extended period of 30 seconds before it closes. The ene rgy conservation service, unaware of this change, forces the door to close after opening for 10 seconds, causing potential injury to the user Scenario D Changing Requirements The programmer of the smart entrance service could hardly call it a day, even after he fixes the problems in Scenario A B and C apparently, everyone has something to say about the door. The owner of house wants the door to remain closed as much as possible to save on the energy bill; the resident asks the door to be automatically secured during sleeping time; even the newly bought in door grill, whose safety day, the programmer has to sew up these fragmented and potentially conflicting pieces of kn owledge in his software, and investigates on the grill to figure out how both services could work together. What is worse, he has to be ready for new challenges as any new device, user, service joining the house could result in a major modification to his software. What seems to be a quick and easy job turns into a laborious and daunting mission that never ends The above scenarios are only a few examples of the numerous potential safety risks created by pervasive spaces. While programs are responsible to e nsure the correct and safe behaviors of their applications, it is not fair to lay the entire burden on

PAGE 21

21 the shoulders of programmers. As shown in the above scenarios, even when each individual service and application is correctly executed, risk conditions m ay still rise as a result of device failure, service conflict, or human and environmental factors. In addition, the lack of safety support in existing programming models invites unrestrained programming practices and often results in awkward and inadequate safety solutions. A safety and encourage more stakeholders to engaging in the creation of safer pervasive systems. Programming Models for Pervasive Spaces By providing simple bu t powerful abstractions, programming models support a broad category of programmers to develop applications, services and a variety of administrative tools and system monitors [33]. These abstractions hide the complexity of pervasive systems away from prog rammers, enabling easier and more convenient programming practices. However, these programming models could also blind programmers with improperly designed abstractions that limit their understanding of the safety details of pervasive spaces. On one hand, some programming models provide excessive flexibility to programmers, encouraging a constrained style of programming, which may invite safety loopholes. On the other hand, the over simplification of other programming models may raise the concerns of losing the expressive power when it comes to specify detailed safety knowledge in their programs. In this section, we survey the existing programming models for pervasive and discuss their inadequacies in safety. The service oriented programming model, a popular paradigm for developing pervasive computing systems and applications, encourages a free and unrestricted style of application composition over available services [6] [7] While this is a powerful

PAGE 22

22 capability to the programmer, it may lead to unpredictable b ehaviors in the pervasive space when the applications are deployed. In theory, a programmer can select any set of services from the service pool and connect them to form an application. Service methods can therefore be invoked in any order. Clearly, such l ack of constraints on service composition may unintentionally but adversely cause conflicts and contentions among the various services. This could create a potentially enormous state space of the system and opens up possibilities for states that are undesi rable, unpredictable or even impermissible An extended version of service oriented programming model has been proposed by [3]. To protect against false and unsafe states of a service, the model defines a prioritized safety API, which mandates the service programmer to supply safety checking instructions and specify preemptive emergence handling methods through a uniform service interface. While this approach improves the safety conditions of individual services and devices, it is less effective to detect a nd resolve competing or conflicting scenarios, which involve multiple services. In conclusion, this model focuses on safety conformance of each individual service, but overlooks the risks brought by the intricate relationships among services such as depend ence and conflicts. The context driven programming model, takes an alternative approach to address the safety issue by monitoring unsafe conditions at a global level [38][39]. Undesired and unsafe situations are specified as impermissible context in a glob al context grid that describes the overall status of the space. At run time, the stream of sensor readings are examined to verify if any safety violation has taken place. While maintaining and monitoring a global context grid could be expensive, a greater problem is, how to create

PAGE 23

23 such context grid and align it with the various safety concerns in the first place. Furthermore, the context driven programming model encourages programmers to delegate all responsibilities of safety checking to the centralized co ntext grid, while many safety concerns could be better internalized and more effectively addressed within the service or the application. The event driven model is similar to the context driven model, but provides a Condition like rule syntax for programmers [2][40][41 ]. The syntax requires a rule processing engine in the pervasive system to constantly monitor for events and conditions, which may incur a significant performance overhead Figure 1 1 demonstrates the tradeoff between the power and expressiveness of a programming model and the safety margin it provides. Context driven model is shown to provide high safety index but falls short in its ability to program many desired applications. On the other hand, service oriented model s offer very high programmability but they fall short in being unrestrained and inadequate to ensuring safety. The figure also shows where the community should invest its efforts in the envelope of both increased programmability and safety. Scope This re search aims at enhancing the safety of pervasive spaces with a new been extended. In addition to programmers, more stakeholders are obligated to engage in the design, develo pment and management of pervasive spaces. In particular, we achieve the enhanced safety by accomplishing the following: Devise a new design and development practice that can enhance the safety awareness of not only programmers, but also other providers a nd suppliers involved in the creation of pervasive spaces.

PAGE 24

24 Development of a new theory that models the execution of pervasive systems from a safety oriented perspective, and defines a set of practicable properties that ensure the safe execution of pervasi ve systems. Design and implementation of a run time mechanism based on the above mentioned theory, that can effectively prevent, or detect and mitigate safety risks in pervasive spaces.

PAGE 25

25 Figure 1 1. Tradeoff between safety and expressiveness of program ming models in pervasive spaces.

PAGE 26

26 CHAPTER 2 LITERATURE REVIEW Introduction Safety, along with other issues such as security and privacy, has been placed into the research agenda of the pervasive computing community for almost a decade While we have seen a plethora of literature over security and privacy research, the outcome of safety research remains limited. In a survey of pervasive computing systems conducted in 2010 [37 ], we found only a few research projects that include safety as their direct objecti ve [27][28][38]. The concept of safety in pervasive computing remains loosely defined, and is sometimes used interchangeably with terms such as dependability and trustworthiness which are compound system properties that involve reliability, availability, security, and safety [41][42][43][44]. In fact, most of these research works rely heavily on reliability/availability based approaches, which stem from the conventional safety engineering. A brief review of safety engineering in conventional industries (in the first section) will show why these concepts/approaches are inadequate in addressing safety concerns in pervasive environments. Then we present of a brief survey (in the second section) over a number of safety related research projects for pervasive co mputing systems. This chapter reviews the existing literature in two directions. First, we survey the recent research in the conventional safety engineering domain. A comparison study is conducted to discuss the common safety approaches among several conve ntional industries. Through comparing the safety issues in conventional industries environments with pervasive spaces, we show why conventional safety engineering

PAGE 27

27 approaches is inadequate. Second, we survey the published work on safety and safety related i ssues that focus on the domain of pervasive computing. Safety Engineering in Conventional Industries Safety is not a novel issue created by the recent pervasive computing technology. In fact, the concept of safety has been closely tied with engineering ev er since the discipline of engi neering starts to take shape [56 ]. As technology continues to evolve, they are brick and steel structures, electrical machineries, or sensor based pervasive systems. The domain of safety engineering has long been established to extensively investigate the issue of safety in a wide range of industries such as transportation, chemical processing, nuclear power, and construction, etc. To prevent, detect, mitigate or recover from the various safety risk scenarios, a plethora of techniques and devices have been invented, codes and regulations have been established, many of which are However pervasive technology also brings forth new challenges for safety. The extensive interactions between cyber and physical worlds extend software failures and logic errors to real damages and physical harms. Furthermore, the close connections between human and computing, further magnify the risks to users when the safety of pervasive computing is compromised. These challenges calls for new perspectives and approaches to safety, which can better utilize the sensor/actuator rich feature of pervasive computing. The issue of safety has been studied extensively for many decades in various conventional industries such as commercial aviation, rail transportation, chemical processing, etc. In this section, we briefly survey the conventional approaches to safety

PAGE 28

28 in each of the above industries. By comparing their various approaches, we attempt to (1) separate the concept of safety from reliability, (2) distinguish the pervasive space engineering from conventional industries, and (3) lay out the new safety challenges in pervasive spaces. Commercial Aviation The safety of commercial aircraft l argely depends on reliability [46 ], which is mainly achieved by (a) single element integrity aircraft components are designed and manufactured to meet the FAA approved failure r ate requirement, and (b) redundancy aircraft are equipped with redundant key components to cope with single or multiple point failure. Aircrafts typically have long product cycles, allowing new models to be carefully improved based on previously known ca uses of accidents. Aviation industry in general is very conservative towards new technology and always avoids drastic changes in their product design. Rail Transportation Rail transportation is one of the sa fest forms of on land travel [57 ]. Unlike aircraf ts, the majority of rail accidents are caused by collisions. Therefore the most important safety measure is train signaling system, which controls train traffic in the railway network to c reate separation among trains [53 ]. Modern train signaling systems u se other train is allowed to enter. The safety and correctness of train control software can be verifie d using model checking tools [58 ]. Chemical Processing The chemical p rocessing industry mainly focuses on three types of safety hazards: fire, explosion, and toxic release [46 ]. The maturation of design and operation

PAGE 29

29 procedures over the years has led to industrial standards and codes to eliminate or contain these hazards. I n chemical industry, most safety approaches emphasis on component reliability and add on protection devices. However, with the use of new technology, and the increase in scale and complexity of controlling systems, the focus of safety has changed from indi vidual components reliability to the overall system integrity [47 ]. The growing risks of human errors and false system interactions have lead to s ystem accidents reported in [59 ]. Safety vs. Reliability As shown in the above survey, reliability has been regarded as an integral property contributing to the safety of overall systems in most industries. Reliability engineering, which concerns primarily with failures, has become a dominant safety approach in conventional industries. Reliability engineer uses a variety of techniques to minimize component failures and thereby the failures of overall systems caused by component failure, including parallel redundancy, standby sparing, built in safety factors and margins screening, and timed replacements [46 ] Al though engineers tend to use the terms of reliability and safety alternatively in many cases, safety and reliability are in fact two different concepts. Increased reliability do not necessarily guarantees increased safety, since not all safety hazards are created by failures. In fact safety is a broader concept than reliability as failures may or may not compromise safety. As the size and complexity of a system increases, the risk of human errors, unsafe interactions, and conflicts can grow significantly, jeopardizing the safety of the overall system even if individual component failures are kept at a low rate.

PAGE 30

30 Pervasive Space Engineering vs. Product Line Engineering Unlike the matured conventional industries that typically have product lines providing e nd to end solutions to manufacture and assemble final products, pervasive space industries are yet to deliver a complete package of smart home technologies as a of a per vasive space so far is largely an ad hoc process that requires lots of hacking and tuning. The lack of standardization in the development process poses additional challenges to safety engineering for pervasive spaces. Unlike conventional products that have fixed life cycles and a finali zed design at the early stage [49 ], pervasive systems often continue to evolve even after its deployment. With new services and devices continues to enter the pervasive space, the purpose and goals of the space also start to shift, leading to a changing requirement of safety. Meanwhile, new risks and conflicts could rise as a result of the changed configuration. Therefore safety can no longer be addressed in a single step of the product design, but needs to be constantly manag ed during its entire l ifecycle. As an example, Table 2 1 provides a summary of the comparisons between an aircraft cockpit and a smart home. R esearch on Safety and Safety related Issues in Pervasive Computing Research on Safety related Issues There are t wo main areas of research related to safety in pervasive computing: system fault tolerance and programming safety. Fault tolerant systems address reliability in pervasive spaces by concentrating on failures of components in pervasive systems. The GAIA Project [60 ] at the University of Illinois at Urbana Champaign

PAGE 31

31 proposed a fault tolerant mechanism that detects device failures in pervasive spaces using heartbeat beacon signals periodically sent by device s to announce their availability. Fault mitigation and containment is typically achieved by redundancy. The Gator Tech Smart House Project [ 61 ] at the University of Florida proposed the of a group of physical sensor s with similar functions. Virtual sensors provide fault resilience by substituting faulty sensors with others in the same group. Another branch of fault healing roc ess transparent to end users [62 ]. The PACE Project [63 ] at University of Queensland suggested a fully automatic reconfiguration and replacement method for fault recovery, owing to their unique execution model. An application of their system reaches con text information along a path called process chain, which is a pipelining of execution units called processes. Such a process chain is starting from physical sensors called atomic processes, and constructed dynamically at runtime, by an extraction from a p redefined process relationship graph. Hence, if a sensor has a fault but no other sensor in the same category is available; the process chain is reconstructed dynamically based on other category of sensors The programming safety approaches focus on progra mming languages and tools to enhance software robustness and safety of pervasive systems. Chen and Motet proposed a technique to embed system safety requirement as control structure s in the programming language [47 ]. Kelly and Weaver introduced the Goal St ructure Notation (GSN) [61 ] as a formal representation for sa fety cases in complex systems [50 ]. Martins et al investigated in type safety in programming language for wireless sensor networks

PAGE 32

32 [48 ]. Programming structures utilizing exception handling mecha nism have also been brought to pervasive systems to handle failur es a nd unsafe situations [43][64][65] Safety Research in Pervasive Computing Despite of a plethora of literature on safety related issues such as reliability, dependability, security, priv acy and trust, not many researchers have directly addressed the issue of safety of pervasive systems. Among the papers claimed safety solutions to pervasive spaces, many narrowed the scope of safety issue and only provided solutions from a particular aspec t of pervasive computing. For example, de Champs et al. focused on the application layer where individual pervasive software and device could be verified usi ng model checking techniques [55 ]. Baskar investigated the interactions among devices and argued co nflicts and interferences among devices constituted major decentralized device regulators to enforce the safety poli cies in pervasive environment [54 ]. Ma et al fi paradigm aiming to construct a conflict free and safe pervasive computing environment using a unified methodology [68 ]. To define the scope of safety, a few more concepts were coined such as u object (including u system and u person) and u environment. A u person is considered to be non negative if he/she does not attack other u systems or u persons. Safety is defined by the absence of negative relationships among u objects. However, in this vis ion paper, no solutions were proposed to address the technical challenges in the paper, such as how risks and attack can be detected. Similarly, Yang and Helal identified the four fundamental elements of safety in pervasive space: dev ice, user, service a nd space [3 ]. A service oriented programming

PAGE 33

33 model was proposed where the safety requirement of the other three elements (device, user and space) are embedded in their correspon ding service representations [21 ]. A safety enhancement mechanism has been devi sed to mandate all services to implement a strict safety interface and register their risk handlers.

PAGE 34

34 Table 2 1 Comparison between aircraft cockpit and smart home. Aircraft Cockpit Smart Home System Architecture Closed Open Safety Goals Fixed Changin g over time Components Tightly coupled; High reliability; FAA regulated Loosely coupled; Variable reliability; Non standardization or regulated Business Model Well established models Roles and models are yet to shape up Evolvability Finalized p roducts; Fully tested Frequent updates, upgrades, & customization; Continue to evolve after deployment

PAGE 35

35 CHAPTER 3 PROBLEM ANALYSIS Safety of pervasive spaces is a broad concept, which involves a multitude of elements ranging from human users to physical e nvironment, from software services to hardware devices. The overall safety of a pervasive space requires not only satisfaction of the various safety requirements for individual elements, but also protection over the extensive interactions among these eleme nts. Safety is also a constant concern spanning all stages during the lifecycles of a pervasive system, which requires a collaborative effort from a variety of roles in the design, development, and management of pervasive spaces. In this chapter, we anal yze the breadth and depth of the safety problem in pervasive spaces, by presenting the results of two preliminary studies. We first dissect the pervasive spaces and summarize four fundamental elements of safety. We then introduce a collaborative model that defines the safety responsibility of multiple roles involved in the lifetime of a pervasive space. These studies help us define the scope and challenges of the problem, and prepare us for an overall safety approach, which will be presented at the end of t he chapter. Fundamental Elements of Pervasive Spaces To understand the scope of safety problem in pervasive spaces, first we need to understand what a pervasive space entails, and where the safety concerns arise from. A pervasive space is a physical space instrumented with sensor and actuator devices, which are managed by software applications and services, to provide assistances to human users. Yang and Helal [3] first propose the four fundamental elements of

PAGE 36

36 pervasive spaces: device, service, user and sp ace. In this section, we analyze each of the four elements and discuss their safety implications. Device The capabilities to interpret and interac t with the physical world start with devices. They are the I/O devices that bridge the gap between the physi cal world and digital realm. Although the complexity, capability, size and other attributes may vary, a device can always be classified as either a sensor or an actuator. Sensor acts as the source of data, which reports the status of the surrounding enviro nment or the device itself back to the system. Actuator, on the other hand, functions as the recipient of commands, with which the system issued instructions are translated into certain action sequences and carried out accordingly. More complicated devices such as smart appliances or robots, which are capable of sensing data as well as receiving commands, can be considered as a combination of sensors and actuators. The notion of safety for a device is two fold. First, the device itself is at a sound state a nd secure from damage, which requires the device to be deployed in a device friendly environment and operated with proper and safe procedures. Second, the device does not jeopardize the safety of the overall space (known as a pervasive space), which includ es other devices and services, users and the physical environment. This requires an individual device to be conscious of the global safety constraints when it interacts with the physical space. Service Service is at the core of any pervasive computing sys tem. The term service is overloaded with various meanings that a clarification is required before we can commence on the following discussion. With any non trivial computing system, we

PAGE 37

37 expect the premeditated favorable outcome or useful functionality to be delivered upon the activation of software artifacts or systems. These functionalities and outcomes can be delivered by a stand alone software artifact or in coordination with others as a group. We use the term service to describe the collection of softwar e artifacts that are involved in the process as well as the sequence of events in completion of this deliverance. Each service is usually designed to fulfill very specific purposes, with very specific requirements on the availability of other services or the existence of configurations in order to accomplish its goals. In the dynamic environment of pervasive computing, a service presents one of the smallest and simplest entities that can be well regulated. User As in any system modeling and analysis, atte mpts to model human behavior is laborious but yet rarely generate any accurate results. User, as one of the fundamental elements of pervasive computing system, cannot be as easily and clearly modeled as devices and services. But users are critical because they have the final say in deciding what the system need to do, and sometimes even how they should be done. Such is true even in those systems aiming at complete automation. Users are the most delicate element in the pervasive space in terms of the tolera nce of any risk factors. Hence a model without user will be incomplete and utterly useless. The bottom line is the systems exist to serve users, and there is no reason for any system to exist if there was nothing users want to achieve. Space Most research ers do not consider the space itself as a critical element of pervasive computing system, but rather only as a collection of services and devices, as well as the interactions among themselves and between them and users. This assumption often

PAGE 38

38 leads the prog rammers to see the trees but miss the forest. A space is an important element because the status of the space as a whole often provides critical contexts for decision making; a space also encompasses all other elements within, in particular the status of s ervices, devices and users as well as the interactions between them; side affects usually cannot be captured by devices or services, but can be described by measurable changes in a space. Based on functions, social contexts and the locale of a space, there are different restrictions and interpretations of the contexts. For instance, the interpretation of cleanness in a clean room will be different from a butcher shop; the acceptable temperature and humidity also drastically differ in an engine room from an operation room. As shown in Fig. 3 1, the four elements enabled a new perspective on the problem and the overall safety condition of a space can be improved by protecting i ts devices from misuse and failures, restraining services from risky and hazardous behaviors, satisfying imposed by the space itself. To break down of the overarching safety concerns into element wise measures and knowledge, we need to first identify the roles for the various stakeholders, such as device manufacturers, service programmers, users and domain experts, who possess a broad range of expertise on each of these eleme nts. Roles and Collaboration Models for the Design, Creation, and Management of Pervasive Spaces Building a pervasive space involves many skilled people. In our lab, it took a team of technicians, programmers, electronic engineers, computer scientists and domain experts working closely with the owners of the space, to design and develop the Gator

PAGE 39

39 Tech Smart House [15]. While it is exciting and enjoyable to have interdisciplinary collaborations in a university environment, few pervasive system developers and space owners would have such luxury to bring together all these skill sets and expertise in the commercial environment. In practice, pervasive technology enjoys a healthy yet fragmented industry market, spanning sensor manufacturers, connected medical and personal devices, the suppliers of networks, middleware and applications for sensor connectivity and integration, and many other smaller pieces of the puzzle. In industry, many companies will concentrate on specific elements of the entire pervasive sy stem. Numerous device manufacturers such as Analog Devices [16] and A&D [17] produce hardware ranging from pin head sensors and actuators to more complex devices and smart appliances. A number of middleware providers such as Pervasa [18] and Augusta System s [19] create middleware platforms that connect applications with devices; and there are all manner of software development enterprises writing applications for a variety of systems. Others take more systematic approaches by providing end to end solutions that focus on specific solutions in the pervasive space. For example, ActiGraph is a company specialized in human activity monitoring. Its products include not only wearable sensors for activity measurement, but also software tools for data collection, agg regation and analysis. Some companies extend their offerings further by providing human services like monitoring centers, coupled with software and hardware in their solution. For instance, most burglary alarm businesses provide installation and monitoring services.

PAGE 40

40 This is a large market filled with many complementary players who bring a wide range of strengths and expertise. What is needed is a playbook, guidelines allowing individual suppliers to position themselves and team with others. While it may loo k obvious that different roles must coordinate to develop a pervasive system, it is not clear how responsibilities and resources should be divided, or how coordination and collaboration is achieved among these roles. Without an accurate articulation of the se roles, an architecture that supports the separation of roles and, a careful design of a business model that inter relates them, it will be increasingly difficult to integrate each pervasive spaces consisting of several roles that undertake different responsibilities at various stages in the life cycle of a smart space. We see the roles in such a development model supported by well designed, loosely coupled system architectures, bas ed on standards that enable the creation and interoperability of these spaces. Early mainframe computers such as the IBM S/360 and ICL 2900 knew only two roles: programmers and operators. As the computer evolved to networked servers and workstations, users systems seem to require new and revised roles to enable a development model that works despite a fragmented technology market and that can utilize existing IT experience in supporting the p ervasive space throughout its entire life cycle. The need of a new collaboration model is even more paramount when we consider the problem of safety, which is broad issue spanning the lifetime of the space from design to operation stage. In addition to com mon physical hazards such as fire and burglary, a pervasive space has many more monitoring concerns: failure of devices,

PAGE 41

41 contention between services, and the safety and well being of users in the space, just to name a few. The distributed nature of safety hazards and protocols is another driver for a correlation of events and a collaboration model that ties in multiple roles. For example, the specification of safety constraints requires combined knowledge from the space owners and domain experts. Compliance with safety rules, in turn, sets obligations on device manufactures, application developers and users. The detection and elimination of safety risks requires collaboration among sensing devices, monitoring personnel, actuation equipment and certain middle ware mechanisms. We need a model that provides a clear separation of responsibilities among these roles and offers a path toward seamless collaboration on development, deployment and the complete lifecycle of pervasive spaces. In the following sub section section, we introduce an ecosystem in which multiple roles can work together to design, develop and maintain pervasive systems with improved safety. A role is a socially expected behavior pattern. It embodies a set of connected rights and obligations. To c reate a collaboration model for building pervasive spaces, we need first to specify the resources and responsibilities of each role in the model. The resources include internal assets such as knowledge, professional skills and budgets, as well as external ones such as device specifications, programming APIs and software toolkits provided by other roles or third parties. The responsibilities describe what is expected from each role to contribute to th e pervasive space. Figure 3 2 gives an overview of these r oles and their relationship in a collaboration model. Some of the identified roles have already been well established in the industry, while others are

PAGE 42

42 terms coined for positions we consider critical to building a pervasive smart space. In this section, we introduce each role in more detail and provide a summary in Table 3 1. General Space Developer General space developers are the general contractors, experts in overall pervasive space development. Qualified general space developers possess the knowledge a nd experience necessary to take charge of design, implementation and deployment of the acquire and integrate various components, and to implement solutions which address those n eeds. Typically, the space developer works closely with the space owner to such as which middleware would best serve as a framework for the system. They are responsible and integrate these components, the space developer hires technicians for the physical installation and deployment. Once the smart space is up and running, the developer hands over th e system to the space administrator for testing and final acceptance. The general space developer is a critical role that coordinates other roles at the various stages of development. Due to the diverse nature of pervasive spaces in different application d omains, general space developers can be expected to specialize in different types of spaces. Space Admin Our experience has convinced us that the essential role of maintaining upgrading and reconfiguring the smart space is often overlooked in its design a nd development [20]. A pervasive system does not stop evolving after its initial deployment. While it is unrealistic to retain the entire development team to make adjustments, a space

PAGE 43

43 administrator will have to cope with frequent device changes and service upgrades. This role covers typical monitoring and response services, and extends to the handling of emergencies and other events in the smart space which require human intervention or er a pervasive space. They evaluate, approve and deploy newly introduced services, and provide first response to safety alerts and other emergency situations. Also they coordinate with space technicians, service providers and device manufactures for servic e upgrades and everyday maintenance Space Technician A space technician is a sub contractor working under the general space developer. The technician role covers many tasks in the construction of the cyber/physical space infrastructure, such as setting up networks, installing servers, controllers and personal computers, and, wiring the sensors and actuators. They follow the physical deployment and integration work. Devi ce Manufacture A device manufacturer supplies products such as sensors, actuators, controllers and networks that constitute the physical layer of a pervasive system. To make a device available to the various services and applications, its manufacturer is obligated to provide detailed specifications of device interfaces and protocols to other roles such as service providers. These specifications can be written in a standard descriptor language such as DDL. The middleware provider or a third party then prov ides software tools which convert specifications into software services, allowing access and control to the device via standards based service interfaces.

PAGE 44

44 Middleware Provider Middleware serves as a running environment to host and integrate a variety of sof tware components To achieve seamless integration of both software services and hardware devices, the middleware provider is responsible for supplying standards based service APIs, a programming IDE to service developers, as well as tools and mechanisms to device manufacturers to assist them in fulfilling the responsibility of device descriptions (as explained in the section 2). In addition, middleware has to provide tools and user interfaces allowing a space administrator to install, configure, and maintai n the system at runtime. Space Service Provider The role of s pace service provider s is to provide implementations of software services based on goals and requirements as specified by the space owner and general space developer This could entail implement ation efforts for developing new or highly customized services, or the porting and reuse of pre existing services. Sometimes, a service depends on the presence or the absence of other services to work properly. Therefore, its providers carry the responsibi lity to explicitly state this dependenc e relationship so that the general space developers and admin istrators will make informed decisions to include or exclude certain services in various configurations. As pervasive systems permeate the globe, it is impe rative to develop collaborative models that enable the various suppliers and providers to efficiently contribute and integrate the resources needed to create smart and manageable spaces. In addition, t each participating role is assigned clear cut responsibilities. Our collaborative model is an attempt to separate

PAGE 45

45 the safety concerns by assigning safety obligations to a variety of roles at different stages of the lifetime of a pervasive system.

PAGE 46

46 Table 3 1. Distribution of resources / responsibilities among roles Roles Business Roles Resources Responsibilities Space Owner Customer Budget Specify goals Approve and accept Hire g eneral s pace d eveloper and a dmin General Space Developer General Contractor Ex pertise in space and s ystem d evelopment Requirement analysis Architectural design Sub contract with other roles Space Technician Sub contractor Skilled labor and services Physical deployment & integration Everyday maintenances Space Administrator Provid es Service s to Customer All inputs, outputs, and configuration options available from Space Runtime monitoring A dminist ers space configuration & software updates ; First response to critical events Middleware Provider Vendor Expertise in pervasive middle ware Provide facilities for service integra t ion Device Manufacturer Vendor Knowledge of its product Specify devices Space Service Provider Software Service Component Provider Programming API Specify depende n cies on devices and other services

PAGE 47

47 Figu re 3 1. Define a safe pervasive space element wise. The set of safe states of a pervasive space is the intersection of the safe states of each element in this space including device, service, user and the space itself.

PAGE 48

48 Figure 3 2 Overview of the multipl e role collaboration model in pervasive space development and management

PAGE 49

49 CHAPTER 4 OVERALL APPROACH Why do We Need an Overall Approach? Safety problems are extrem ely diverse in pervasive spaces, so are the techniques utilized to detect, prevent or rec over them Can we protect the overall safety of a pervasive space, by simply combining these techniques to address each and every safety issue we can identify? In this section, we argue that such ad hoc solutions will not be feasible, and that an overall s ystematic safety approach is necessary to address the diverse safety needs in an open and complex pervasive environment. An a d hoc a pproach typically addresses a specific safety issue with a closed set of risk scenarios. This approach work s well with many closed systems that have fixed use cases, however, it is not flexible enough to address the safety need in a n open pervasive environment whose applications may be constantly evolving In addition, ad hoc approaches often utilize dedicated devices and serv ices, which are not meant to be shared with other applications. The lack of programmability on these closed boxes further impedes their ability to adapt to new and customized safety requirements. Ad hoc safety approaches also do not scale well with pervasi ve spaces. As the numbers of users, devices, and services in pervasive spaces increase, the number of cyber physical interactions grows e xponentially, which opens a vast amount of possibilities for new risk scenarios. Addressing each safety risk by a new a d hoc safety technique seems inefficient and wasteful. It is more desirable to have an overall approach where devices, services, and knowledge can be reused to handle new safety issues. In addition, conflict and contention becomes a major safety risk facto r as a consequence of the rich interactions in pervasive spaces. Ad hoc approaches, often

PAGE 50

50 intended for closed sub systems run in isolation, cannot address this category of safety risks. Therefore, a systematic approach to manage, regulate, and protect the concurrent interactions between the physical space and cyber world is needed. Challenges As we quest for an overall approach to address the safety issue, we encounter a number of challenges First, integration of safety knowledge and concerns. A systemat ic safety approach requires a uniform understanding of safety based on the collective knowledge from different stakeholders from various domains. The lack of a standard safety language impedes the integration, consolidation and utilization of these safety knowledge and concerns. Second, enforcement of safety rules and constraints. Unrestricted interactions between pervasive systems and physical spaces could create undesirable consequences violating the safety needs of the space. A runtime enforcement mech anism is needed to reduce the risk of these violations. Third, evaluation of safety mechanisms. Enforcement of safety constraints can be achieved in different ways at various costs Finding the most cost effective way requires performance evaluations on s afety enforcement mechanisms. Identifying performance metrics, synthesizing benchmarks, and establishing performance models could be challenging. The Approach This dissertation presents a safety oriented programming model that aims to address the abo ve challenges. Our programming model embodies two main ideas (1) a domain independent ontology for safety, which addresses the fragmentation of safety

PAGE 51

51 knowledge and concerns by proposing a universal vocabulary for safety concepts, that empowers various s takeholders, in addition to programmers, to formulate safety constraints in uniformed semantics. This allows the creation of an integrated safety knowledge base, which provides safety guidelines for runtime safety mechanisms. (2) a novel concept of pervasi ve transaction, which models the interactions between the cyber and the physical space as transactions. This concept provides possibility to utilize database transaction processing theories to manage the safety of pervasive spaces. A Domain independent On tology for Safety The main idea of a domain independent ontology for safety is t o enable different parties to collaboratively specify and seamlessly integrate their safety concerns over various aspects of the pervasive space. As we discussed in Chapter 3, pervasive computing systems can be dissected into four fundamental elements, each identified as a source of risk that carries certain safety concerns. Based on these elements, we create an ecosystem to establish several roles through the lifecycle of a per vasive space. These roles, separated by distinct responsibilities and resources, collaboratively contribute their own safety concerns and knowledge by using a small and scalable ontology over the universal concerns of safety. This ontology is independent o f any application domain and offers a unified expression of safety constraints. We name this ontology as DiOS (domain independent ontology for safety). With DiOS, a stakeholder in the ecosystem is able to specify safety constraints in universal safety conc epts. DiOS can also be used as an extension to a domain specific language, such as device descriptor or user profiling languages. This will enable specification and integration of safety requirements from parties of various application domains.

PAGE 52

52 Pervasive T ransaction The idea of pervasive transaction originates from an interesting analogy that we observed between pervasive systems and conventional database management systems. A database controls the use and maint ains the integrity of the database, which is a collection of shared data objects. Database transactions perform read and write operations to access and manipulate these data objects concurrently Similarly, a pervasive system is deployed in a certain physical space, whose state is observable and contr ol lable through sensing and actuations, which are logically equivalent to read and write operations. This analogy reveals a leverage opportunity to approach the safety issue in pervasive spaces in a way similar to approaching atomicity, consistency, integr ity, and durability (ACID) in database. Analogous to database transactions, we propose the concept of pervasive transaction s as a general programming model for safe application development in cyber physical spaces. In this model, we use context to represe nt the state of the physical world. A pervasive transaction therefore is simply a sequence of read/write operations over context, which results in a context transition of the pervasive space. Since according to our approach, pervasive transaction is the on ly form of interaction between the cyber world and the physical world, we can improve the overall safety of the pervasive system by runtime transaction management. Safe transactions will be processed and committed. R isky transactions will be restrained and /or aborted. And c onflicting transactions will be isolated. We took the idea of pervasive transaction one step further, by proposing context lock a runtime mechanism that protects the physical ext lock achieves isolation among pervasive transaction through access control. By adhering to a locking protocol,

PAGE 53

53 execution of conflicting transactions will be separated in time and resolved. We further employ context locks in enforcing useful notions of durability in pervasive spaces. Finally, we propose safety transaction a system controlled transaction issued by pervasive systems to recover the space from a risky context, and/or safely abort risky transactions. The Scope This dissertation research ai ms at providing system wide safety support to per vasive spaces (shown in Figure 4 1 ). To address the above challenges, we propose a two fold approach. First, we present an ontology based programming model, which enables the fusion of scattered and fragment ed safety concerns and knowledge from a broad range of roles into an integrated safety knowledge base. Second, to enforce safety constraints from the integrated safety knowledge, we devise a runtime mechanism to regulate the operation of pervasive systems based on what we call the theory of pervasive transaction. The core of the programming model is a small but scalable ontology over the universal concerns of safety. This ontology allows roles from different domains to express distinct knowledge and concer ns using the same safety vocabulary. With this ontology as a semantic base, we are able to embed unified expressions of safety constraints in device specifications, user profiles, service descriptions, and space configurations, and collect them in an integ rated safety knowledge base. The run time enforcement mechanism bases itself on the theory of pervasive transaction, which establishes an abstract model of the interactions between pervasive systems and physical spaces. In this theory, the execution of a p ervasive application is modeled as a transaction, consisting of a number of sensing and actuation operations.

PAGE 54

54 Our run time mechanism ensures the maximal conformance of safety constraints by regulating the execution of pervasive transactions. In the event o f safety hazard, the run time mechanism also composes and invokes safety transactions to restore the pervasive space to a safe and stable state. The rest of this dissertation is organized as following. We introduce DiOS, a domain independent ontology fo r safety in Chapter 5 Then we present the Device Description Lan guage (DDL) in Chapter 6, as a case study of utilizing DiOS ontology to collect safety concerns and knowledge from devices. In Chapter 7, w e introduce a formalization of safety using the conc ept of pervasive transaction s. The detailed implementation of pervasive transactions is presented in Chapter 8 In Chapter 9, we evaluate the performance of our implementation by presenting an analytical model and numerical results We conclude this work w ith a summary in Chapter 10.

PAGE 55

55 Figure 4 1. Overview of safety architecture for pervasive spaces, which is divided into system wide (left) and program wide (right) safety support.

PAGE 56

56 CHAPTER 5 DIOS: A DOMAIN INDEPENDENT ONTOLOGY FOR SAFETY Creating pervasi ve spaces requires us speaking a new language of safety. Given the scale and complexity of most pervasive systems, there cannot be a single designated role for safety A clearly defined common safety vocabulary is needed to allow a variety of programmers, providers and suppliers to exchange, share and eventually integrate their safety knowledge and concerns. The Domain independent Ontology for Safety (DiOS) is small but scalable ontology that defines the universal safety concepts independent of the domains of applications. DiOS consists of two distinct yet related ontologies: DiOS Core and DiOS Periphery. DiOS Core defines the core vocabularies for specifying safety concerns and knowledge. DiOS Periphery, extended from the core ontology, establishes a generi c model of pervasive spaces, which includes various elements pertinent to the issue of safety. Figure 5 1 presents the overview of the DiOS ontology DiOS Core The root of the DiOS Core ontology is the OWL class ctx: Context Context is a conceptual abstra ction of the physical state of pervasive space s The simplest form of a t 75 degrees context Context can be classified as safe or unsafe base d on the domain knowledge of the experts The rest of the DiOS Core ontology is divided into two parts : (a) a safety classification of context, which defines the semantic terms to separate context according to the level of safety, and (b) a taxonomy of con text compositions which defines a set of key concepts constituting a context. We describe each part of the ontology in the following subsections.

PAGE 57

57 Safety C lassification To describe the safety level of a particular context, DiOS defines four safety classif iers : risky for context with potential damage, severe for elevated ri sk and ongoing damage, desirable for safe and preferred context and neutral for context that is neither unsafe nor desirable. Both risky and severe context are impermissible context whe reas desirable and neutral context are considered as permissible context Therefore, the overall safety of a pervasive space can be described as the conditions of all context entities. A space is considered unsafe if an impermissible context exists Safety is a complex issue involving both subjective perceptions and objective piece of context carries different safety implications and entails different actions, when it is assessed by people with different perspective, domain knowledge, and interest. On the other hand, the risky (or safe) phenomena represented by the context are factual and independent of personal opinions. In addition, the pervasive system needs a coherent view of the overall space safety despite of the separated concerns and interest of the various stakeholders (such as users, space owner, device manufacturers, and service providers) in the space. Therefore it is important to make sure our ontology accommod ates both the subject and objective nature of safety. When a stakeholder uses the classification system to address a safety concern, there should be a clear separation between the physical reality and the personal opinion. Another problem involving the de sign of the safety classification is to justify its adequacy. We frequently face questions such as: How detailed the safety classification system should be in order to be adequate? Why not add (or remove) a safety level from DiOS? Would a quantitative appr oach be more precise than quantitative classification?

PAGE 58

58 To answer these questions, we based our design on the following considerations. First, safety is a spectrum From the very safe and desirable, to extremely risky and hazardous, we can always divide sa fety into many varying degrees depending on various criterions. No matter how many levels we have, we could always design a classification that is more detailed and precise. Even if we have a classification system that is perfectly adequate for one applic ation, we can never guarantee it is equally adequate for another. Therefore, we should shift our focus from adequacy to utility Our goal here is to design a minimal but universal separation that is useful and reasonable for all applications. We come up wi th four safety categories in our design based on the discrepancy of both urgency and system reaction. With the urgency of situation changes, the pervasive system changes its mindset and responds in different ways. This serves as a guideline for stakeholder s to address their concerns at proper safety levels, establishing reasonable expectations of the system behavior should a safety risk occur. Desirable Context Desirable context are states not only safe but also preferred by its stakeholders such as users and the space owner. Under a desirable context, a pervasive system is required to do nothing but trying to maintain this context. A piece of desirable context and transitions within desirable contexts will not trigger any drastic or urgent responses from t he system. Neutral Context Neutral context denotes states that are under protection but not preferred by any stakeholders. Neutral context are considered to be safe. While a transition from a neutral context to a desirable context is preferred, it is not required. Therefore, like desirable context, a neutral context will not trigger any drastic or urgent responses from the pervasive system. However, the system may upgrade a neutral context into a desirable context. Risky Context Risky Context describes states when safety risks occur and create pending damage or harm to the space. A pervasive space under risky context is no longer considered to be safe although the actual damage has not occurred. Risky context presents the best opportunity for a pervasive space to recover and avoid lost of property or life. The pervasive system is required to respond

PAGE 59

59 immediately to all risky contexts. The actions taken to convert a risky context to a permissible context are called lossless recovery Severe Context When r isk elevates and causes actual damage, the hazardous states constitute Severe Context Like risky context, severe context is also impressible and must be responded immediately. Under a severe context, a pervasive system can either retreat to risky context or a recover to a permissible context. Context C omposition In DiOS, context is an overarching concept that describe s the state of the entire perva s i ve space or a subset of the space. A context can be described by the state of a single context entity, a co ntext entity set, or a situation. Each of these three concepts is defined by its corresponding class in the DiOS ontology document Context Entity The OWL class ctx: Context Entity defines a logical entity that represents elements of various natures in th e pervasive space, including conceptual entities such as software services, and physical entities such as objects, devices, users, and the physical environment. To describe the status of a Context Entity each entity has several attributes ( Entity Attribut e ) taking values in their corresponding domains. For example, the physical environment is a Context E ntity with Entity Attributes such as temperature, humidity, and luminance. Therefore, we can characterize the state of the physical environment by a vector of its attribute values, e.g. [temperature, humidity, luminance] = [76 F, 50%, 50 cd/m 2 ]. In a pervasive space, the values of these Entity Attributes are acquired by sensors and other approaches such as software probes and logs. Context Entity Group A c ontext in pervasive spaces can also consists of a group of context entities. The OWL class ctx: Context Entity Group defines a set of related context e ntities Context entity groups are usually used to characterize certain phenomenon or events, which invol ve a group of context entities, each changing its own states to reflect such phenomenon or events. For example, DUI physiological signs such as blood alcoholic level and the and orientation. In addition, within a context entity group, there are attributes describing the relationship among entities. These attributes do not belong to any individual entity, and are defined as group attributes. For exampl e, the distance between two objects is a group attribute when the objects are in the same context entity group. Situation [ 43 ] Situation is a temporal sequence of context. The ctx: Situation class has a member class ctx : Context Entity Group for the group of context it is keeping track of, and a property class ctx:Situation Attribute that describes time information

PAGE 60

60 of the context, such as the timestamp of each context snapshot, and the time interval in between context. DiOS Periphery DiOS Periphery present s a context based abstraction of pervasive systems. A pervasive system contains two types of devices: sensor and actuator. A sensor performs sensing operations, which reads from its corresponding context entity, while an actuator performs actuations, which modifies the corresponding context entities. Any pervasive application, therefore, is abstracted as a series of read and write operations over various context entities. DiOS Periphery defines a generic model of the pervasive space and provides a top level taxonomy of the elements in the space. It also defines the relationship between these elements and the DiOS Core ontology. DiOS Periphery is domain independent yet domain aware. The model of pervasive spaces provided by this ontology is independent of any applications, making minimum assumptions on the system architecture and implementation of the space. (For example, DiOS models the Oriented Architecture.) At the same ti me, DiOS Periphery is aware of the various application domains and offers an open framework for further extensions from domain specific ontologies. In DiOS Periphery, domain specific concepts will be subsumed and aligned with the generic ontology, making i t possible to represent domain specific concerns and knowledge within a domain independent framework. The root of the DiOS Periphery ontology is the OWL class pvs : Pervasive Space which is also the root of the taxonomy of the pervasive space elements. The Pervasive

PAGE 61

61 Space class contains three top level elements: (i) Physical Space (ii) User and (iii) Service Physical Space The pvs: Physical Space class defines vocabularies for describing the physical aspect of the pervasive space such as its temperature, humidity and luminance. Typically a pervasive space has exactly one instance of the physical space, which can be described by a set of its environment attributes. To align this ontology with DiOS Core, the Physical Space class is defined as a Context Enti ty while the Environment Attribute is defined as an Entity Attribute Depending on the interest and requirement of individual spaces, the set of environment attributes of a space is extensible to include customized, domain specific attributes. For example in a bathroom environment, it is interesting to know the temperature of both the air and the tub water. Hence, we can add a irTemperature and w aterTemperature as two sub classes extended from the attribute Temperature User User is an important element in addressing the safety issues in pervasive spaces. On one hand, the profile of a user provides valuable information that may reveal the and social identities can be u tilized to infer desired or unwanted contexts of a user. On and physiological conditions themselves are often critical signs of risky and unsafe situations. The usr: Use r class consists of typical vocabularies for describing both the static profile and the dynamic status of a person. To align with the DiOS Core ontology, class User is defined as a subclass of Context Entity

PAGE 62

62 Servi ce The third element, service, is a key co ncept to model the system (cyber) side of the pervasive space, which sets itself apart from the physical space. We define service as a unit of system component that delivers a set of functionalities by invoking its service methods. An important property of class Service is Service Method We define a service method by the transition of context caused by invoking the method. The context before a method invocation is defined as Precondition and the context after its invocation is defined as Effect Although our service ontology is alluding to a service oriented architecture (SOA) employed in the pervasive space, it does not necessarily mandate one. In fact, the concept service is loosely defined in DiOS and intended to cover similar concepts such as process and task in other programming models and architectures. Device Service Although services are typically considered as software entities, a hardware device can also become a service when it is properly wrapped by a software representation. We define thi s type of service in class Device Service as a subtype of Service DiOS Periphery is both domain independent and domain aware. The ontology establishes a model of the pervasive space that is independent of any domain of applications, making minimum assumpt ions on the architecture and implementation of the pervasive system. Meanwhile, DiOS Periphery offers an open framework for further extensions from specific domain. The top level taxonomy in DiOS Periphery, defines a set of generic concepts, allowing domai n specific knowledge such as user profiles and device specifications to extend from with the generic ontology. Therefore, DiOS make it

PAGE 63

63 possible to integrate domain specific concerns and knowledge within a domain independent framework. Summary DiOS provides the semantic basis for uniform specifications of safety rules and constraints. In the following chapter, we show how we extend a device description language with DiOS vocabularies to specify safety concerns and knowledge for devices.

PAGE 64

64 Figure 5 1 Overv iew of the DiOS ontology.

PAGE 65

65 CHAPTER 6 DDL: UTILIZING DEVICE INF ORMATION FOR SAFER P ERVASIVE SPACES Introduction With the massive deployment of sensors, actuators, and everyday objects enhanced with communication and computing capabilities, pervasive comp uting is pervading almost every aspect of our daily lives, raising ever growing concerns for safety. As pervasive systems close the gap between cyber world and physical spaces an imminent risk of extending logical failures and computing errors to physical damages and real harms, because of their capability to interact and influence the physical world. Restraining this capability from turning into harmful even destructive forces requires our attention on its technology enablers sensor and actuator devices. This chapter aims to address the issue of safety in pervasive spaces from a device centric perspective. fol d. First, the device itself is at a sound state and secure from damage, which requires the device to be deployed in a device friendly environment and operated with proper and safe procedures. Second, the device does not jeopardize the safety of the overall pervasive space, which includes other devices and services, users and the physical environment. This requires an individual device to be conscious of the global safety constraints when it interacts with the physical space. By protecting the safety of each individual device in operation, we expect to enhance the overall safety of the entire pervasive system. An interesting observation is made when we use the concept of context to represent the state of pervasive spaces. The safety of pervasive spaces rel ies on the ability of pervasive systems to (1) monitor and discover risky context through sensors,

PAGE 66

66 and (2) actively rectify or mitigate unsafe context through actuators. Sensors and actuators together, while presenting challenges to the safety of pervasive space as points of concerns, also reveal the opportunity as part of the solutions to this very issue. The goal of this chapter, therefore, is not only to restrain sensors and actuators from risky and unsafe operations, but also to unleash the power of the same devices by engaging them in the monitoring and protection of the pervasive spaces. In this chapter, we address the safety issue in pervasive space, by focusing one special element: device. We seek answers to two fundamental questions about safety fro m a device oriented perspective. First, how does a device understand, and inform of the notion of safety? With each device in the pervasive space carrying its own safety knowledge and concerns, the notion of safety is constituted by scattered, sometimes co nflicting pieces of information. Presenting an integrated and consolidated view of safety based on the collective knowledge from all stakeholders requires a uniform semantic framework allowing devices to express, exchange and share these safety knowledge a nd concerns using domain independent concepts. Second, how can we make devices participate proactively and intelligently to respond to unsafe scenarios? Existing safety and security applications control devices by following explicit rules and policies. For example, alarm is triggered when the house is broken into; or sprinkler is activated if a fire is detected. These are rules pre defined or hardcoded in the application logic. However, asking users and programmers to specify rules for each and every potent ial risk scenarios is not a scalable approach. It would be more desirable for systems to automatically enact devices to mitigate and eliminate the risky context. For example, when a door is left open at night, a system should be intelligent enough to

PAGE 67

67 disco ver the door actuator and invoke the device to close the door. This ability to discover and invoke device services requires each device to effectively communicate its capability and identify its link with the risky context. This chapter reports on our rese arch efforts to answer the above questions. We start by a brief introduction to the Device Description Language (DDL), which is a base language to which we extend with safety features. Then we show our approach to the first question by introducing several DiOS enabled language constructs, which allow device manufacturers to specify their safety concerns and knowledge in universal terms within a uniform language structure. With DiOS and DDL, device manufacturers are able to express their concerns and knowled ge in universal safety concepts within a uniform language structure. To answer the second question, we first present a device model that reveals a sensor actuation link using the concept of context. Inspired by this sensor actuation link, we then bring a t hird component to our language framework: a domain ontology for sensor taxonomy (DoST). DoST allows each device to inform of its domain of operation, which is an important clue for pervasive systems to discover and coordinate proper devices to cope with va rious safety risk scenarios. The chapter closes by surveying the related work and summarizing our own contributions. Introducing DDL: the Device Description Language DDL is an XML based markup language that allows device manufacturers to publish the speci fications of their products in a digital form. DDL covers a wide range of sensors and actuators. Each DDL device descriptor contains: (a) meta information of a device for service registration and lookup, and (b) descriptions of communication interfaces bet ween a device and external services. By providing a language processor that automatically converts a DDL device descriptor to a service bundle, responsibilities

PAGE 68

68 among device manufacturers, system integrators and applications programmers can be distributed and clearly separated [1] For each device, its manufacturer will provide the integrator can then run the ATLAS DDL language processor [24] to create an OSGi bundle fo r the device, and upload it to the device repository to make the service readily available for application programmers. After a device bundle is created, it is uploaded to the Atlas Bundle Repository Once a device connected to an Atlas node powers up and joins the network, the Atlas middleware, which listens on a variety of network interfaces, will identify the device and access the Bundle Repository to retrieve the service bundle. When a reference for such bundle is loaded, applications and other services are able to dynamically discover and access it using OSGi provided mechanisms. DDL was originally designed and developed to enable automatic integration of a variety of devices [ref]. As our research proceeds, we repurposed DDL as a carrier of safety con cerns and knowledge for devices. In this paper, we focus on the safety extensions to the language. We present more details of DDL in Appendixes: the DDL data model in Appendix A, the DDL schema in Appendix B, and a sample DDL descriptor file for a temperat ure sensor in Appendix C. The complete manual of DDL and the source code of the language processor have been released and are accessible online at http://www.icta.ufl.edu/atlas/ddl Expressing Safety K nowle dge and Concerns Device safety is an integral part of the overall safety of pervasive spaces. Many sensors and actuators deployed in the Internet of Things are primitive, pin head sized chips that are vulnerable from harsh conditions and physical damages. For other devices, some built in protection mechanisms are in place. However, they usually do

PAGE 69

69 not cover every risk scenarios and cannot guarantee the total safety of the devices in use. Most devices still require users to be conscious of its vulnerability at the time of deployment and operation. We identify the following four categories of risk factors that devices could be exposed to in pervasive spaces. Hostile environment The physical limitations require most devices to deployed and operated in a friend ly environment. Harsh conditions such as extreme temperature, humidity, radiation, high levels of chemical substances, motion and Interference Existence of some devices could cause interferences to others, and affect their normal operations. Interferences are considered hazardous to mission critical devices. For example, airplanes ban the use of cell phones to avoid interferences to avionic devices. Misuse To ensure the proper op eration, many devices require their external users to follow certain procedures, which define the permissible sequence of interactions, and the boundaries of acceptable parameters. Violating the procedure could cause a device to enter a wrongful and unsafe state. For example, an application that repeatedly invokes a door actuator at 100 times per minute could break the actuator when the device no longer withstands the metallic fatigue. Internal failures Devices could fail due to internal software or hardw are errors. Some failures are critical, which could compromise the safety of the device itself and the space as well. For example, an ill programmed firmware on a sensor node could cause self heating, and eventually burns the node. Although these failures cannot be prevented by external precautions, they needed to managed and controlled in a timely fashion to avoid propagation and escalation. Protecting devices from the above safety risks requires deep and detailed knowledge of devices from system integra tors, service developers and users, who will deploy, program and interact with these devices at different stages of the pervasive system. Clearly, safety has put on extra burden to all above stakeholders as they have to go over a variety of manuals, specif ications, and safety codebooks to collect these knowledge. Not to mention that safety rules and policies written in natural language are often vague, inaccurate and inconsistent.

PAGE 70

70 Our approach redistributes the responsibility for safety by engaging one mor e stakeholder: the device manufacturer. Device manufacturers possess the most in depth knowledge about their products. Hence it is natural for them to assume the role of specifying the safety needs of devices. To further extend their power, we provide a de vice description language that allows the specification of safety constraints in a uniform structure, and a tool that automatically converts device descriptors into software components that oversees the safety of the device. In the remainder of this sectio n, we first introduce DiOS, a minimum ontology that defines the core safety vocabularies. Then we present DDL, the device description language and its implementation that utilizes DiOS vocabularies for representation and integration of device safety knowle dge. The following elements are added to the DDL schema to enable safety support in the language. Context Constraint Context constraint is a syntactic structure allowing DDL descriptors to specify safe (or unsafe) context for devices. Context constraints are mostly used to describe environment requirement of devices such as operating temperature and humidity. The structure of a context constraint includes a context description and a safety classifier Context description specifies the context entity to be constrained, and the range (or set) of values for the context entity. DDL allows both built in and user defined context entities. The built in context entities currently support four most common context domains: temperature, humidity, luminance and accele ration. To create a user defined context entity, the user needs to specify the entity name, value space, unit, and sensor type associated to the context entity. The range (set) of values specified in context

PAGE 71

71 description should be a subset of the value spac e, measured in defined units. The safety classifier is a predicate that asserts the safety level of the described context. DDL supports six classifiers as defined in DiOS vocabulary: permissible, impermissible, desirable, neutr al, risky and severe. Figure 6 1 shows an example of a context constraint for an ambient light sensor using the built in context entity temperature. Conflict List DDL allows each type of device to specify a list of conflicting device types with which it could interfere. There are tw o ways to specify a conflicting device. One can specify a device directly by name and model, or indirectly by domain of the device. Name and model attributes together, uniquely identify a device type. However, a device may conflict with a general type of d evices with many individual models. Specifying devices by domain is therefore more convenient in these situations. A domain is a special attribute in DDL that classifies a device based on its field of operation. For example, we consider a heater and an air conditioner are potentially conflicting because they both operate in the domain of temperature. We will describe the concept of device domains in more detail when we introduce a domain based taxonomy of devices in the next section. Fail safe Method Fail safe methods are actions to ensure a device cause no harm, or minimum harm to the space in the event of failure. Fail safe methods vary upon devices, which may include shutdown, network cutoff, and recovery to a safe state, etc. Not every device has fail safe features. To specify a fail safe method in DDL, one needs to tag a device method fail safe 2 shows a DDL snippet of fail safe methods for Type 3374 31 electric actuator. Type 3374 31 actuator is a linear

PAGE 72

72 actuato r commonly used with a valve in heating, ventilation and air conditioning (HAVC) systems for buildings. The following code snippet specifies the actuator stem fully retracts (which keeps the valve open) as a fail safe action. In addition to above features DDL also specifies operation protocols for devices, which regulate the interactions between a device and its users. DDL comes with a what we call device service bundles. A device service bundle is a virtual representation of a physical device. To protect a device from misuse, a bundle provides a constrained service interface, which limits the sequences and frequency of method invocations, as well as the boundaries of param eters. Other devices and services can only interact with the device through its service interface. A device service bundle also contains the context constraints of the device. When a device powers up and joins the network, its corresponding service bundle will be activated and submit its context constraint to an integrated safety knowledge base. Detailed description of DDL language processor and device service bundles is presented in [1]. We present ed only the extension in terms of concepts and specificatio n (DDL schema as shown in Appendix B) but the current implementation of the DDL language processor has yet to support these extensions With DDL /DiOS we are able to specify safety constraints for individual devices and collect them into an integrated saf ety knowledge base, which makes possible a global approach for safety: a single device in the pervasive space can rely on the overall sensing capability of the entire system to monitor for its undesired context, and the overall actuation capability to miti gate when risky context occurs. However, one

PAGE 73

73 question remains: in the event of an impermissible context, how does the system know which proper device to actuate to avert/mitigate the context? Engaging Devices in Risk Mitigation To proactively engage devic es in risk mitigation requires pervasive systems to understand the relation between safety risks and participating devices. In our approach, we model this relation by the concept of context. In the following section, we present an abstract model of devices that reveals the link between sensor, actuator and context. Devices: a Context Based View We classify devices in pervasive systems into two basic types: a sensor that observes and an actuator that affects, a particular domain of the physical space. Most d evices in the pervasive space can be considered as either a sensor, or an actuator, or a combination of both. As defined in DiOS, we use the term context entity to denote a ith these two concepts, we are able to link a sensor and an actuator together if they operate within the same domain. For example, we can say a thermostat (sensor) is a reader of temperature (context entity); and an AC a writer of temperature. When a undes irable scenario such as over heating arises, we can use a thermostat to monitor and detect, and an AC as a potential candidate to resolve this undesired context. We define context entity as a conceptual entity that represents the domain of a sensor or an a ctuator [9]. A context entity has a value space and a metric. A sensor is a physical or virtual entity that performs sensing which is a read operation over a context entity; an actuator is a physical or virtual entity that performs actuation, which is a w rite operation over a context entity. A more formal definition of the above concepts can be found in Chapter 6.

PAGE 74

74 The concept of context entity changes our understanding of devices, which brings several benefits in addressing the issue of safety. First, it d efines the scope of the safety problem for pervasive systems. While there are many safety risks and hazards in the pervasive space, not all of them are detectable by pervasive systems. The safety responsibility of pervasive systems is bounded by its sensin g and actuation capabilities. A pervasive system should only be accountable for safety issues in domains accessible to the system; in other words, the safety conditions that can be represented in context, readable and modifiable by its sensors and actuator s. Second, context enables an abstract yet accurate representation of safety concerns and knowledge. On one hand, existing safety rules and constraints represented in natural languages could be too abstract for pervasive systems to practice. On the other h and, modeling risky conditions and phenomenon directly by sensor readings is accurate but less re usable. These models are often deployment specific (e.g. depending on sensor locations, types and models, etc.) and not suitable for general safety knowledge and concerns. Context representation provides the right balance between abstraction and accuracy, which is ideal for describing safety knowledge. Third, context reveals the link between sensors and actuators, providing an important cue for discovering prop er actuations to recover from unsafe context. DoST: a Domain Ontology for Sensor Taxonomy Pervasive systems should be capable to assign the proper sensors for detection, and the proper actuators for mitigation, when risky context arises in certain domains (i.e. context entities). If each device can specify its domain of operation, pervasive systems will have better clues to search and match devices with various risk scenarios. This requires a standard taxonomic scheme to classify and organize all domains of devices.

PAGE 75

75 The Domain ontology for Sensor Taxonomy (DoST) is our attempt to define such taxonomic scheme. While there are many types and models of sensors and actuators, we observe that there is only a limited set of domains within which they operate. There fore, a classification of device domains is practically feasible. We create the DoST ontology by surveying most commonly available sensors in the market. Although DoST can also serve for actuators, we are only interested in sensor domains because: (1) actu ator domains largely overlap with sensor domains; (2) safety risks are eventually represented in sensor readings. Actuators operating in domains invisible to sensors are not useful in risk mitigation. As shown in Figure 6 3 DoST has a hierarchical structu re, with class ContextEntity at its root. Every sensor domain is a context entity. DoST define four top level domains: space, pervasive object, device, and user. Each of these domains is further divided into more sub domains. For example, space domain incl udes weather, sound, luminance, flame, chemical level, etc. Pervasive object includes sub domains such as identification, location, orientation, presence, size, speed, weight, etc. We incorporate DoST in DDL by allowing devices to specify their domains of operation in t he DDL descriptor. With DoST, a pervasive system is more informed of the capabilities of its devices, can more effectively discover and enact devices to cope with risky conditions. Sensors and actuators, instead of being mandated by strict a pplication logics, can now voluntarily participate in critical tasks for safety monitoring and risk mitigation

PAGE 76

76 Summary Many existing pervasive applications focus on monitoring the safety of the environment [26][30], human [27] and infrastructures [28][29] However, the safety of devices has remained a largely unexplored area. In addition, many existing safety applications extensively use sensors for safety monitoring; but only a few report the use of actuators to mitigate from risk conditions [31]. Moreove r, all systems surveyed above have specific and predefined safety risks to protect against. Our approach distinguishes itself from the related work cited above in the following ways. First, we do not assume or predefine specific safety risks. Instead, we p rovide a language framework allowing stakeholders to specific any safety concerns using a general context abstraction. Second, we address safety from a device centric perspective. We find a device, as a point of interaction between the cyber space and phys ical world, could directly cause physical harms and damages. Restraining devices from wrongful and risky operations gives us the best chance to enhance the space safety. We also find safety of devices is an important aspect contributing to the overall safe ty of the space, which requires us to understand the limitations of devices and follow their operation procedures. Third, our approach utilizes actuators in addition to sensors. Pervasive systems possess the power to actively affect the physical space thro ugh actuations, which can be used to modify unsafe and impermissible context and mitigate from risk conditions. We aim to unleash this power by linking actuators with sensors using the concept of context.

PAGE 77

77 < Sensor > < Description < Constraint > < ContextDescription entity temperature > < Range > < Max > 100 40 < Unit > Centigrade < SafetyClassifier > Desirable < / Description > < Interface > A TMD5510FX01 ambient light sensor manufactured by Vishay, Inc. Figure 6 1 TMD5510FX01 ambient light sensor and its DDL snippets. (The snippets define the sensor support operating temperatures from 40 C to +100 C.) < Actuator > < Description > < Interface < Method fail safe yes > < MethodName > retract < Parameter name travel_distance value 15 unit mm > < Parameter name actua te_time value 12 unit s > < Parameter name positioning_force value 500 unit N > < / Interface > A Type 3374 linear actuator attached to V2001 globe valve by Samson, Inc. Figure 6 2 Type 3374 31 electric linear actuator and its DDL snippets. (The snippets define the fail

PAGE 78

78 (a) Top level taxonomy of DoST (b) Partial view of DoST showing the taxonomy branch for temperature Figure 6 3 A Snippe t of the DoST ontology.

PAGE 79

79 CHAPTER 7 FORMALIZING SAFETY I N PERVASIVE SPACES Motivation Pervasive systems bear some resemblance to database management systems. A database management system controls the use and maintenance of the database, which is an integra ted collection of shared data objects. Transactions are executed on the database by performing read and write operations to access and manipulate these data objects. Similarly, a pervasive system is deployed in a certain space and maintains the physical st ate of the space, which is logically represented by a collection of context entities in the system. To access and control the state of the space, applications in a pervasive system invoke sensing and actuation services to perform reads and wri tes on variou s context entities In database, failures and concurrency are the two sources of potential errors that lead to inconsistent states of data. We find a similar class of problems in pervasive systems that are raised by the same factors. For example, a sensor failure could cause false readings of the context, leading to incorrect interpretations of physical state of the space (such as a false positive or true negative detection of a safety risk). An actuator failure could result in a failed attempt of modifyin g contexts, creating an unknown state of the space. In addition to device failures, service and applications could also fail due to logical errors and erroneous executions, giving rises to inconsistent and false states in the physical world. Even with faul tless applications that are correctly executed, concurrent executions may also create scenarios of conflicts where applications are contending to access and change the same context. For example, one application wants to keeps the light off, while the other wants to kept it on. The light will be turned

PAGE 80

80 on and off repeatedly, which causes a volatile and undesired state of the space. We generalize this class of problems by the term of safety problems in pervasive spaces. Despite the similarities between the t wo types of systems, distinctions should not be neglected. First, data stored in databases are digital while context describing the physical properties of the space, in some sense, can be analog In database, the value of a data object takes discrete sta tes. A write operation changes the value of data from one state to the other. There are no intermediate states in this operation. However, in pervasive spaces, many physical properties are continuous. For example, actuating the AC to change the room temper ature from 85 degrees to 75 degrees is a continuous process in which the state of the temperature context takes a gradual change. Therefore, the first implication of this analog property of the pervasive space is that there exists a temporal relationship b etween actuations (the operation) and context entities (the operand). While write is simply considered as an assignment of value in database systems, actuation can be modeled as a temporal function of context entities in pervasive spaces. The second implic ation is fuzziness Data objects in database system take exact values. But in many cases, it is practically infeasible to maintain the same exactness when we describe the physical properties of a pervasive space. Following the previous example, if the AC m anages to settle the room temperature at 74.9 degrees, do we really consider the actuation has failed? Clearly we need to introduce the concept of fuzziness to context descriptions for pervasive systems. Secondly, databases are closed systems where only read and write operations from the database management systems are allowed to access and manipulate data.

PAGE 81

81 Pervasive systems, in contrast, are usually deployed in a space open to external factors such as environment effects and human activities. Unlike data base, pervasive systems do not have the exclusive access to modify the state of context entities. Physical dynamics and human activities in the space can also bring in uncontrollable, and sometimes unpredictabl e, modifications to the context Last but not least, database systems and pervasive system have very different goals. The primary concerns of database are the integrity and consistency of data protected by properties known as ACID (atomicity, consistency, isolation and durability), while pervasive sp aces typically aim to maintain a safe and desirable state of the space by carrying a number of explicit or inexplicit constraints. Although we have identified that both pervasive systems and database shared a mutual class of risk factors such as failures a nd concurrency, it appears that the concerns and criterions of both systems are not equal. For example, actuating an AC in the room while reading from a of traditional dat abase. But should it really be a concern in the pervasive system? While it is strongly suggested that pervasive systems bear some transactional nature, the original ACID properties are not suitable to describe this nature and therefore need a revisit. Revi siting ACID properties for Pervasive Systems ACID is the set of properties that regulate the processing of transactions in database management systems. Here, we extend the concept of transaction to pervasive spaces, to represent a unit of execution of per vasive services, which consists of a number of sensing and actuations, similar to read and write operations in

PAGE 82

82 databases. Formal definitions of transaction, sensing, and actuation can be found in the following sections Atomicity In database, atomicity me are performed. Therefore, all operations of a transaction are treated as a sin gle, indivisible, atomic unit [12]. Atomicity rules out the possibility for incomplete transactions in database: a tra nsaction is either processed to its entirety or not processed at all. Scenario B in Section 2 demonstrates a case where the non atomic execution of services creates an impermissible intermediate states. However, the violation of atomicity does not always l ead to compromise of safety. It is okay to cancel a transaction in the middle of its execution as long as the resulted intermediate state is safe. In addition, atomicity implies the ability to rollback when a transaction cannot proceed. While it is easy to cancel the effect of write operations on a data object, it is much more difficult and costly to rollback an actuation that changes the physical state of a space. In many cases, it requires compensating actuation operations to restore the space to its prev ious state. Therefore, the property of atomicity requires a relaxed definition for the new purpose of safety. Consistency Consistency requires that a transaction maintain the integrity constraints on the database. These integrity constraints have been larg ely relaxed in pervasive spaces. Slightly different than its original meaning in database, integrity of a pervasive space indicates that each entity in the space always remains in a safe state. A pervasive

PAGE 83

83 system protects integrity of the space by eliminating transactions that could lead to a undesired or risky state (we call impermiss ible context). Isolation Isolation demands that a transaction execute (as though) without any interference from other concurrent transactions. S ame principle holds true for pervasive spaces: ideally, a pervasive application should not worry about others to ensure its correct execution. Isolation also implies exclusiveness. A transaction in execution has exclusive access to the context entities it modifies. But this is much more difficult to achieve in pervasive spaces, where external factors such as environ ment changes and human activities could always interfere with its execution. While it is unreasonable and practically impossible to isolate pervasive systems from the external world, at lease some level of isolation can be achieved by separating conflictin g services within the system. Durability In database, durability means that all the changes made by a successfully terminated (committed) transaction become permanent, surviving any subsequent failures. To achieve such persistence of data, database managem ent systems typically employ replications and recovery techniques. Unlike database, which always attempts to recover to a particular point in its state space, a pervasive system only requires the persistence of subspace, which is a set of permissible state s of the space. When failures and natural hazards take place, a pervasive system will try its best effort to recover the space to any permissible state. To summarize, the meaning of durability in pervasive space has largely changed: while the effects of ap plications do not need to be permanent, the pervasive space desires a lower degree of persistence by trying to

PAGE 84

84 survive from failures and always restore itself to a safe point of its state space, we call permissible context. Context, Context Entities, and C ontext Envelope The notion of context for pervasive space has been extensive ly discussed in the literature However, none of the existing definitions adequately serve the purpose to define our transaction model. In this section, we present our own definit ion of context and introduce an associated concept: context entity. In a pervasive space, sensors perceive the state of the physical world. Each sensor produces sensor readings, describing a certain aspect of the physical world. All sensors in the space to gether, define the perceived state space of physical world. We context is simply a point in this context space. Context and Context Entities We introduce the notion of conte xt entity as a conceptual entity to refer to a example, room temperature becomes a context entity if there exists a temperature sensor available in the space. If we m corresponding context entity becomes the operand that the sensor is reading upon. affected by multiple actuations. Hence a context e ntity is associated with only one read operation, but 0 to many write operations. Context entity brings a powerful notion to our work because it changes our perspective, as illustrated in Figure 7 1, and reveals a new link between sensors and actuators: th ey are reading and writing to a shared set of

PAGE 85

85 actuators. Formal definitions of the concepts described above are presented in Def initions 7 1 to 7 3 Definition 7 1. Conte xt Space. For a sensor S i in the sensor set S = {S 1 S 2 S n } of a pervasive space P the readings of S i are of domain D i The context space of P is defined as a vector space C P = D 1 X D 2 X X D n Definition 7 2 Context and Context Vector A context is a point in space C P represented by an n tuple: c = (d 1 d 2 n ) C P where d i D i Given two contexts c 1 C P and c 2 C P we define a context vector v = < c 1 c 2 >, representing a transformation of context from c 1 to c 2 The projection of context ve ctor v on domain D i is represented by d i where d i is the unit vector of domain D i Two context vectors v 1 and v 2 are of opposite directions, if D i such that v 1 d i and v 2 d i are also of opposite directions. Definition 7 3 Context Entity A context entity e i is defined by a 2 tuple: e i = (S i A ) where S i is the sensor that senses the state of the entity, A is the set of actuators that could change the state of the entity. A can be an empty set. The state space of e i is defined by the domain of S i : D i For a context space C P the set of all context entities is denoted as E P In the above definitions we assume each sensor has exactly one domai n of sensing. In practice, when there is a device with multiple domains of sensing, we can split this device into multiple logical sensors. For example, a blood pressure monitoring device monitors both systolic and diastolic pressure, which can be represen ted by two logical sensors: systolic pressure sensor and diastolic pressure sensor. We also

PAGE 86

86 assume the domain of each sensor is a totally ordered set : { D i < i }, where D i is the set of all possible readings, and < i is the ordering relation. This assumption is natural since most sensors produce numeric readings or readings convertible to numeric values, i.e. domain D i R where R is the set of real numbers and totally ordered. A few exceptions are mainly signal recording sensors (such as image and acoustic s ensors), where we have to manually impose the ordering for their readings. Context Envelope piece of context is a snapshot of the space, recording the state of the pervasive spa ce at a particular point of time. Imagine a space expert examining through a deck of these snapshots. If the snapshot demonstrates a safe and pleasant state of the space, he will ill be labeled their labeling. If the deck of snapshots exhausts all possible states of the pervasive space, then we derive a division of the context space into three sub spaces: impermissible context space ( I ), desirable context space ( D ) and neutral context space ( N ). This division of context space is called a context envelope (D efinition 7 4 ). Figure 7 2.a shows an example of context envelope that divides a space with three context entities: temperature, humidity and luminance. Using this context envelope, given any context, we can quickly determine its safety implications. Note that D I N are not necessarily continuous spaces. For example, there could be several disconnected

PAGE 87

87 D representing the several desirable context spaces in our visualization of the context envelope (Figure 7 2.b). A context envelope is a conte xtual specification of safety knowledge and concerns. While these safety knowledge may originate from multiple stakeholders such as user, domain experts and application programmers, and are represented in various forms such as safety documents, user profil es, and device manuals [ 11 ], context envelope provides a uniform representation of all these safety constraints and preferences that can be managed and interpreted by the pervasive system. The procedure to generate and maintain a context envelope is simila example described previously. A pervasive system at runtime maintains a global running context envelope. The context envelope is updated when a new safety constraint is inserted, or an existing constraint is removed. Any stakeholder can specify a simple domain independent safety ontology. Definition 7 4 Context Envelope. The context envelope of C P denoted by ( C P ) = { I D N } is a division of C P into three sub spaces: impermissible context space I desirable context space D ( the notation of desirable context space D is in bold font to be distinguishable from the domain of a context entity D ) Neutral context space N such that : 1. N I D = C P ; and 2. I N = D N = and I D = If a context c N D we say c is in context envelope ; otherwise c is outside the context envelope

PAGE 88

88 The global context envelope changes over time. Arranging these varying envelopes along the time axis enables an interesting perspective, what we call the tunnel view of context envelopes (Figure 7 3). A tunnel is a set of overlaid context envelopes that sets the boundary between context spaces over time. For example, in Figure 7 3, the vertical dashed lines outl ine the boundary between I and N D We name the outer part of the boundary I tunnel, and the inner part N D tunnel. Therefore, the goal of our safety protocol is to ensure the state transition of pervasive space (as indicated in bold arrows) stays withi n D tunnels as much as possible while avoid penetrating into I tunnels. Sen s ing and Actuation s In our model, sensing and actuation are the only operations that allow a pervasive various context entities. A sensing operation reads a single context entity by invoking a sensor to take a measurement, and returns the sensor reading as the result of the operation ( Definition 7 4 ). The case for actuations is slightly more complica ted, as a single actuation may involve multiple context entities. Consider an actuation ActuateDoor Assume there exists a door actuator service that opens and closes a door, and a few sensors that read the following context entities: door_status temperat ure and smoke_density We can define the ActuateDoor actuation as a write operation over door_status Once such actuation is invoked, its effect over the door_status entity is clear and predictable. For example, if the ActuateDoor command with a paramete r door_status unless failure occurs. According to our common knowledge, the

PAGE 89

89 other two context entities, temperature and smoke_density may also be affected direct relations Definition 7 4 Sensing Operation. A sensing operation, denot ed by r ( e ), is defined over a context entity e and returns the reading of the single sensor associated with e D efinition 7 5. Actuation Operat i o n An actuation operation, denoted by w ( e, d ), is defined over a context entity e and a parameter d D e e i s called the written entity of operation w and d is the intended value to be written to e A sensing operation r ( e ) returns d upon the completion of w ( e d ), if w succeeds. In addition to changing the written entity e an actuation w may also affect other context entities, what we call the set of affected entities A w = { e i | e i e and e i E P }. The relation between actuation w and its affected entity e i is described an affect function as defined in Definition 7 6 Definition 7 6 Affect Function An aff ect function i over context entity e i is a probability distribution function over domain D i Given an actuation w with an affected entity e i A w we use i ( d ) to denote the probability that r ( e i ) = d d D i upon the completion of w Hence, i n contex t space C P a completed actuation w is a transformation of context, represented by a context vector w = < c pre c post >, where c pre c post C P Affect functions allow us to explore the hidden relations between actuations and context, and use actuators to i ndirectly affect our context space, which empowers our safety mechanism in two ways: first, the pervasive system has more complete

PAGE 90

90 knowledge to determine the safety implication of a requested actuation; secondly, in risky and unsafe situations, the pervasi ve system has more options to escape from impermissible contexts by exerting effects indirectly through an actuation. Although deriving a useful and accurate affect functions is not the focus of this paper, we expect two possible approaches to be utilized: (1) system configuration that allows programmers and space administrators to manually specify the function through common knowledge and observations; (2) system learning that relies on the system itself to learn the effects of actuations through the histo ry of sensor readings. Three things can be learned to refine the knowledge of an actuation : Affected Entities Sensor readings are indications of whether a certain relationship exists between a sensor and an actuator, which help to learn the set of affecte d entities of an actuation. Unit Vector If a relationship exists between a sensor and actuator pair, observing the direction of sensor reading changes would help derive the unit vector for the context transformation. Probability Distribution Function The ultimate learning possible is to derive the probability distribution function that indicates how likely a context will be achieved after an actuation is executed. Pervasive Transaction s A pervasive transaction comprises a unit of work performed in pervasi ve systems. The basic components of pervasive transactions are sensing and actuation operations, which operates within the context space of the pervasive system. The goal of pervasive transaction is to maintain the safety of the pervasive system A pervasi ve transaction represents a transformation of context mutually agreed on by the transaction requestor (typically a pervasive application) and the executor (the pervasive system). A pervasive transaction commits (denoted by CMT ) if the promised context is d elivered; and it aborts on failures. Unlike database systems, which mandate

PAGE 91

91 invalidation of all updates on an aborted transaction, pervasive systems are more tolerant with inconsistency issues, and do not require an exact invalidation. However, failed tran sactions may result in undesired and unsafe situations. To ensure the space stays at a permissible context when the transaction aborts, the system needs to enact proper transactions to recover the context to a safe range a process we call fail safe abort (denoted by FSA ). The formal definition of pervasive transaction is presented in Def inition 7 7 Definition 7 7 Pervasive Transaction. A pervasive transaction T i is a partial order with ordering relation < i where 1. T i { r [ e j ], w [ E k E m ] | e j E P E k E P E m E P } { FSA i CMT i }; 2. FSA i T i iff CMT i T i ; 3. if t is FSA i or CMT i for any other operation p T i p < i t; and 4. if r [ e ], w [ E ] T i then either r [ e ] < i w [ E ] or w [ E ] < i r [ e ] The above definition of pervasive transaction is almost a dire ct translation of transaction from the conventional database definition. However, coming into the realm of pervasive computing, this definition suffers from insufficiency of expressiveness in the following aspects: First, in pervasive spaces, typically a t ransaction is issued to with the intention to achieve a certain context. Even if all operations inside a transaction are successfully carried out, it is still possible that the expected context is not delivered due to interferences from natural events and human factors. Therefore committing a transaction should not be depending on the completion of operations, but rather the

PAGE 92

92 fulfillment of intentions. The current structure of pervasive transaction cannot express this notion of intention. Secondly, many perv asive applications are time sensitive, which means if the underlying transactions fails to deliver the intended context within a desired time window, the system should also abort the transaction. Last, many pervasive application not only wishes its intende d context to be realized, but also persist for a while. Consider a sleep application that closes the window before resident goes to sleep. If another application re opens the window immediately after the completion of the sleep application, it would defeat the purpose of the sleep application entirely, despite its successful completion. Definition 7 8 Improved Definition of Pervasive Transactio n. A pervasive transaction is represented by a four tuple: PT i = (T i i TO i TTL i ), T i is the partial ordering of ope rations as defined in Definitions 7 4 and 7 5 ; i is the target context envelope of the transaction; TO i is the time out window for the transaction to enter i upon the completion of its operations; and TTL i is the time to live ticket for the transac tion to remain within i after commit. One benefit of introducing the concept of transaction into pervasive systems is that it enforces isolation to avoid conflicting operations during execution. However, the notion of conflict requires re thinking when we consider the concurrent nature of pervasive systems. As we shift our focus from data/context consistency to safety in pervasive spaces, our transaction model should define a more cope able criterion for isolation that preserves the way pervasive systems o perates, as well as eliminates those operations that raise safety risks. Our model provides two levels of isolation: the

PAGE 93

93 conflict based isolation that prevents simultaneous actuations on common context entities, and the compatibility based isolation that s eparates transactions based on based isolation provides a more relaxed concurrency control without significantly compromising the safety of pervasive spaces. Definition 7 9 and 7 10 define conflict and compatibil ity respectively and the concept of isolation is presented in Definition 7 12 Definition 7 9. Conflict. Two operations are in conflict with each other, if 1. both operations are actuations, denoted by w 1 [ E 1 ] and w 2 [ E 2 ]; and 2. their write sets contain co mmon context entities: E 1 E 2 Two transactions T 1 and T 2 are in conflict with each other, if w 1 T 1 and w 2 T 2 such that w 1 and w 2 are in conflict Definition 7 10. Compatibility. Two write operations w 1 = < c pre1 c post1 > and w 2 = < c pre2 c post2 > are incompatible, if vectors < c pre1 c post1 > and < c pre2 c post2 > are of opposite directions. Two transactions T 1 and T 2 are incompatible with each other, if w 1 w 2 w 1 T 1 and w 2 T 2 such that w 1 and w 2 are incompatible. AI 2 D safety AI 2 D Propertie s Definition 7 11. Atomicity A pervasive transaction is atomic if it either commits or fail safe aborts at the end of execution. Definition 7 12. Integrity Integrity is violated if current context c is outside the context envelope i.e. c I More spe cifically, a pervasive transaction T i satisfies the

PAGE 94

94 integrity property if the post conditions of all actuation operations of T i are not impermissible: w T i such that for w : c pre c post c post D N. Definition 7 13. Isolation A pervasive system satisfies (a) conflict based isolation if there exists no concurrent conflicting transactions during execution, and (b) compatibility based isolation if there exists no concurrent incompatible transactions during execution. Definition 7 14. Durability A context space transaction satisfies the property of durability if its intended context survives the time to live period. Define Safety Using AI 2 D Properti es Based on the transactional model presented above, we give our definition of AI 2 D safety in Definition 7 15 Definition 7 15. AI 2 D safety A pervasive system is AI 2 D safe if the executions of all pervasive transactions within the system satisfy the prop erties of atomicity, integrity, isolation and durability Note that our definition is different from the common notion of safety. By saying a capabilities: (1) the perva sive system will prevent all self incurred safety risks; and (2) the pervasive system recovers from a safety risk only if such risk is detectable

PAGE 95

95 Figure 7 1. The concept of context entity enpowers a new perspective of sensor actuato r relations in perv asive spaces Figure 7 2. Visualization of context envelopes in 3 Dimensional (Fig. 7 2.a) and n Dimensional (Fig. 7 2.b) context spaces.

PAGE 96

96 Figure 7 3. The tunnel view of context envelopes.

PAGE 97

97 CHAPTER 8 PERVASIVE TRANSACTIO N IMPLEMENTATION Introduction The concept of pervasive transaction enables a fresh perspective of safety management in pervasive systems. In this perspective, the interactions between pervasive systems and physical spaces are abstracted as pervasive transactions. A pervasive transacti on is unit of execution consisting a number of sensing and actuation operations over context. The overall safety requirement of a pervasive space is abstracted as a context envelope. To maintain the pervasive space within the context envelope at runtime, w e need to not only regulate and manage the behavior of pervasive transactions, but also proactively enact, what we call safety transactions, to recover from impermissible context. The AI 2 D (atomicity, integrity, isolation and durability) properties togethe r, provides a clear definition of the safety criteria, which serve as guidelines for the execution of pervasive transactions. This chapter describes the implementation of pervasive transactions. We first introduce the runtime management of pervasive transa ctions, by presenting the state diagram of a pervasive transaction. We explain each state in the diagram and present FAIL_SAFE ABORT and EXECUTE. To implement the i dea of fail safe abort, we introduce safety transactions, which is a recovery technique by utilizing existing sensing and actuation capabilities of pervasive systems. Then we introduce the context lock protocol, which regulates the execution of pervasive t ransactions by a variation of lock concept, which we call context locks.

PAGE 98

98 Pervasive Transaction Model In this section, we present a full model of pervasive transactions. We aim to address the following aspects of pervasive transactions in our model: (1) lif ecycle, which consists of several different stages spanning from its creation to termination (abort or commit); (2) formal structure, which defines the necessary operations and parameters needed to formulate a pervasive transaction; (3) programming interfa ce, which presents the tools for programmers to submit pervasive transactions. Pervasive Transaction Overview chapter) is a unit of execution in a pervasive system. It consi sts of a sequence of read and write operations defined over context entities, to represent the interactions between the cyber system and physical space. Pervasive transactions are issued by various programmer is provided with a transaction interface (as a library in a programming language), which allows the programmer to assemble and custo mize available operations into transactions and embed them in the application program. Pervasive Transaction Lifecycle The pervasive transaction theory, at its core, is a model of the interaction between pervasive systems and physical spaces based on the concept of pervasive transaction. A pervasive transaction, as defined in Chapter 7 is a unit of execution within the pervasive system which consists of a number of sensing and actuation operations. In this section, we describe the run time management of pervasive transactions.

PAGE 99

99 As shown in Figure 8 1, the lifecycle of a pervasive transaction is divided into six stages: INITIALIZE, SENSE_OR_ACTUATE, EXECUTE, PRE COMMIT, COMMIT, and FAIL SAFE ABORT. We introduce each stage in the following sections, and pres ent a summary of state transition rule in Table 8 1. INITIALIZE : the starting state of transaction management. At this stage, a pervasive transaction enters the transaction processor, which prepares its execution by assigning the needed resources to the tr ansaction. After the INITIALIZE state, a pervasive transaction starts its normal operation in a two state loop between SENSE_OR_ACTUATE and EXECUTE. SENSE_OR_ACTUATE : the preparation state for a pervasive transaction to perform its next operation, which is either a sensing or actuation. At this state, the transaction requests all context locks needed for its operation to gain accesses to the relevant context entities (LCK_REQ). If all context locks are granted (LCK_GRT), the transaction proceeds to the EXCU TE state. If any of the context locks are rejected by the context lock manager (LCK_REJ), the transaction declares its failure by entering the FAIL SAFE ABORT state. When the transaction finishes the execution of all operations (TR_COMPLT), it enters the P RE COMMIT state. The detailed protocol for context lock management will be presented in Section: Context Lock Protocol. EXECUTE : the execution state where a single operation of the pervasive transaction is performed. At this state, the transaction processo r performs a sensing or actuation operation by invoking its corresponding sensor or actuator service. If the execution succeeds (EXEC_S), the transaction returns to the SENSE_OR_ACTUATE state to prepare for its next operation. The transaction is forced int o the FAIL SAFE

PAGE 100

100 ABORT state if its execution fails due to any of the following reasons: (1) failure of the underlying device services (EXEC_F), (2) revoke of a previously granted context lock (LCK_RVK), and (3) detection of impermissible context during the execution (EXEC_F). PRE COMMIT : the state where a pervasive transaction waits to commit after all its operations complete (TR_COMPLT). This state assigns a time out window for the effects of the completed transaction operations to stabilize. If the stabil ized context enters the target context envelope within time out window (WAIT
PAGE 101

101 Pervasive Transaction Operations In our pervasive transaction model, we provide three types of operations over context entities to programmers: read, write and free. Read and wr ite are similar to the corresponding database transactions, which access and update the operands (context entit i es) respectively. Free is a special operation for pervasive transactions that empowers programmers to free a certain operand from isolation con trol. This is an important feature of our pervasive transaction model because our model design in based on the premise that perfect isolation is neither necessary nor feasible in utilize application knowledge and enable a more practical and efficient transaction processing protocol. We will introduce a few more relaxations in our definitions of read and write operations. Definition 8 1. General Notation of Operations. A general f orm of operations in a transaction is where i is the index of the transaction, j is the index of the operation within transaction T i k is the index of the context entity. Definition 8 2. View Dependency. For operations [ ] and in transaction T i is view dependent on [ ] if the view of provided by [ ] affects we can also say is dependent on the view of In our transaction model, an operation [ ] is view dependent on another operation by default if precedes [ ] in transaction i.e., However, our model also allo ws applications to specify exceptions to this default rule using the free operation.

PAGE 102

102 Definition 8 3 Free Operation A free operation, denoted as signifies an explicit permission of transaction to give up isolation protection over the context entity (for example, through releasing the lock over ). With a operation, declares that any following operation is not view dependent on is willing to allo w other transactions to access Once is freed by transaction subsequent operations over the same context entity are disallowed in Definition 8 4. Read Operation. A read operation in transaction denoted as is defined over a context entity and are the transaction index and the operation index within the transaction respectively. A read operation returns a reading of the context entity. As discussed previously, there may be operations following in that are dependent on Therefore it is necessary to ensure the view of (i.e., the reading returned by ) must be consistent with the reality when such dependency exists. W hen is interfered by other transactions or external events and cause its value to fluctuate, the magnitude of such fluctuation should be bounded to avoid affecting We introduce a novel approach in which our pervasive transaction model allow s for read operation to be defined under such fluctuations. We allow programmers to assign an optional fluctuation threshold parameter to the read operation as the boundary of fluctuation allowed on as the programmer and application semantics se e fit. When unspecified, the default value of is 0. The full notation of read operation is defined as which requires the read operation to satisfy the constraint The latter is formally defined as follows:

PAGE 103

103 Definition 8 5. c onstraint At any point during the effective period (as defined in Definition 7 6) of the value of should satisfies: is the value of at the time when starts to be processed. Definition 8 6. Effec tive Period. The effective period of an operation is the time period during which there is at least one operation including itself in that is dependent on For the purpose of simplicity, we use shorth and notation to represent a read operation in this document, indices and optional parameter appear in our notations only when they are relevant to the discussion. As introduced in Chapter 7, a write operation is an abstraction of the actuation process on the context level. The simple form of a write operation is: which represents an actuation with intended effect on context entity is a value in the domain of i.e., A close examination of the above definition brings a few questions. First, using a specific value to represent the intended effect assumes that the actuator has at least the same resolution as its corresponding sensor. This is not true for many devices. For instance, the resolutions o f most air temperature sensors (0.1 or lower) are much higher those of most air conditioning systems (1 or higher). Such mismatch in resolutions can create problems when writes are issued using alone, e.g., consider writing temperature to 22.5 while there are only 22 and 23 on the dial of the AC. In addition to the degraded resolution, actuators often have limited precisions. A precise write to a specific intended value would be infeasible for many actuators. To accommodate the need for more real istic actuations, write operations

PAGE 104

104 should relax the requirement on intended context by specifying a margin of deviation as allowed by the application. Second, the current definition of write operations makes no assumption of the temporal effect of ac tuations. Many actuations in pervasive spaces are not instant (unlike write operations in database systems). It takes time for an actuator device to interact with the physical space and progress into its intended effect. The duration of an actuation does n ot necessarily stop when the actuator completes its action or motion. Consider a window opener as an actuator that manages in door air temperature. There is usually a time delay between the device action (opening the window) and intended effect (temperatur e settling into the intended range). A practical definition of write operations should take into consideration such delayed effect of these actuations. Allowing write with delayed effect reveals a large class of actuations: actuations through human inte ractions. For this class of actuations, the actuators are human, who are commanded or persuaded by the system to take actions to derive intended contexts and effects. The system initiates an actuation by providing commands or persuasion cues to a human use r, who is expected to follow the actuation command by performing specific actions. An example of such actuation is a medicine dispenser/reminder, which notifies (say, by a voice message through a speaker) the user when it is time to take a pill. In this ca context entity to check if the patient has taken her medicine before issuing the reminder (actuation command) and in case not, to verify if and when the action is taken following th e actuation command. Unlike physical actuators, humans act on their own will and are less predictable in completing these system cued actuations. Tolerance with time delay

PAGE 105

105 or failure in human execution should be considered when we use write operation to mo del these interactions. Third, as we discussed in Chapter 7, there is a desire for durability the post effect of an actuation (i.e., the achieved context of a write operation). However, as discussed in Chapter 7, durability in the context of pervasive t ransactions is different from that in the context of databases, and is limited to an extent of time (e.g., minutes, hours, or until a specific context envelop is reached). To achieve durability, we assign a er a write operation completes, its achieved context will be protected for the duration of the durability window. In light of the above observations, we extend the definition of write operation with three optional parameters: for range relaxation, for temporal relaxation, for durability relaxation. A write operation is defined as following: Definition 8 7 Write Operation. A write operation in transaction is denoted as where op erand is a context entity, and are the transaction index and the operation index within the transaction, respectively. Parameter is the target value intended to be written to The rest of the parameters are defined as: Definition 8 8 Parameter Optional parameter is the deviation relaxation threshold that specifies the maximum tolerated margin of deviation (we call margin) for the context derived by the write ( post actuation context ). A write operation is considered succes sfully completed only if post actuation context margin specification: i.e., Definition 8 9 Parameter Optional parameter, is a temporal relaxation window (we call window), which specifies the maximum co mpletion time allowed for

PAGE 106

106 the write operation. window opens when the transaction processor starts processing the corresponding operation and closes when the elapsed time counts to If a write operation cannot successfully complete within window (due to either physical/human actuator failure or physical interferences), the write operation is considered failed and the corresponding transaction will be aborted. Definition 8 10 Parameter Optional parameter is the durability relaxation window (we call window), which specifies the minimal time required for the post actuation context to endure. window opens when the corresponding operation is successfully completed, and closes when the elapsed time count s to The window is intended for dual use safeguarding against frequent actuation and ensuring minimal durability. The post actuation context is durable if during window, the context always satisfies the margin specification, i.e. for any in window. When unspecified, the default values for the above option parameters are (no deviation allowed), (only instant actuation allowed), and (no requirement of durability). For the purpose of simplicity, we use shorthand notations or to represent write operations in this document, indices and optional parameters and appear in our notations only when they are relevant to the discussion. Pervasive Transaction Use Cases As introduce d in the previous section, the free operation and additional parameters and are designed to provide enriched safety semantics to our pervasive transaction model. In this section, we use a few use case scenarios to show case how our pervasive tr ansaction model benefits from these designs, and empowers

PAGE 107

107 programmers to compose safer and more practical applications in pervasive environment. Scenario A A U se C ase for The traffic law in China mandates that highway toll stations should release tol l gates (free of toll charge) in conditions of heavy traffic to avoid congestions. A smart toll station system can be developed using a traffic sensor (such as inductive loops in roadbeds) to detect traffic volume (context entity ) and an automatic gate as an actuator. The gate opens to release traffic if the reading of exceeds a pre assigned threshold, and closes if otherwise. Because the traffic volume is a real time value that changes constantly, one undesirable but possible situation would be that the gate opens/closes frequently as a result of the fluctuation of above and below the threshold value. Assigning a parameter to traffic volume sensing can address this problem, as it ensures the transaction would tolerate some fluctuation of traffic resulting in calmer and smoother traffic controls. Scenario B A Use Case for Conflicts arise as each service and application competes to derive the optimal context of its own. For example, two temperature control services (as agents representing two different users) may compete for AC control when both users are present in the same space. A conflict will arise, when their optimal temperature settings are different (despite the possibility that they may be close). Translating to our pervasive trans action model, this means at least one of the transactions will have to be aborted. Parameter allows for opportunities for resolving such conflict by providing reasonable relaxations for intended context. In this case, if (i.e., intended temperature is (i.e., ), the space will utilize the s to

PAGE 108

108 determine a mutually acceptable temperature of This relaxation makes it possible for our transaction processor to use a single physical actuation to implement two concurrent logical writes (to temperature as a context entity). Therefore no transaction will be aborted in this case. Scenario C A Use Case for Overcrowding is a safety concern in public spaces such as clubs theaters, and stadiums It is required by law that the population in such spaces shoul d not exceed their designed capacities. To enforce these regulations, a smart space can utilize sensors (such as presence sensor and cameras) to monitor its population. In the event of an overcrowding situation, the space can lock down the entrances and pr ompts inhabitants to exit the space through visual or audio cues. However, this is no guarantee that these actions will achieve the desired effect (of decreased population) due to many factors. For example, visual or audio channels may not be effective in a busy environment, or inhabitants are simply unwilling to follow the prompt. Even if the persuasion channel is effective and inhabitants eventually follow the persuasion cue, the time delay between the actions and the derived effect will be not negligible How long is the application willing to wait? Parameter enables a programmer to assign such time window to actuations to wait for delayed effects to materialize. In our case, if the population decreased below the capacity within the programmer assigned window, the actuation is considered successful; other wise, it is considered failure and will cause the transaction to abort, which would typically require the space to enact stronger actions (such as alarms or calling law enforcement) to enforce the regulations.

PAGE 109

109 Scenario D Use Cases for In Chapter 1 we described a scenario where a door actuator, represented by a software service, is subjected to over frequent actuation (constant interchanging locking and unlocking) because the service fails to impose proper restrictions on its usage. Parameter pr ovides the semantic power for such restriction. By allowing a transaction to specify a durability window ( window) for a door actuation, we will be able to prevent another actuation from immediately overriding its achieved context. (Because the other act uation has to wait for at least time before it acquires access to the door actuator.) window is also useful when an application intends its achieved effect to last. For example, a smart house automatically locks its doors and windows at night for secu rity. Such effects (locked doors and windows) are intended to last throughout the night, leading to a long live transaction. By assigning a window ( in this case will be the length of the night) to the actuation, the space will be responsible to ensur e the durability of such effects within window. During this window, transactions attempting to unlock the doors and windows will be denied access. When external factors (for example, a human) override such effects, the space will notice a violation of t he constraint, abort the transaction, then enact a safety transaction to recover (by re actuating the door and window locks), and report such violation to the users/admins (if the person who unlocked the door is unauthorized). Scenario E A Use Case for Free O peration Falling is one of the most fatal hazards for elderly people in their homes, as well as for workers in construction sites. One technique to detect falling is to use 3 axis accelerometer A sudden burst of vertical acceleration s uggests a high possibility of falling, which calls for certain emergency actions to be taken (for example, contacting caregivers in the elderly home scenario,

PAGE 110

110 and strengthening safety harness in the construction site scenario). Translating these scenarios to pervasive transactions, we would use a read operation to represent acceleration monitoring, followed by one or multiple write operations to represent the actions to be taken. However, one problem with this translation is that a pervasive transaction, by default, prohibits its view from changing after its read. In other words, if the accelerometer reading changes after the fall detection, the transaction would is an unnecessary requirement once a fall is detected, the emergency actions should be completed, regardless how the accelerometer reading changes afterwards. We address this problem by using the free operation. By assigning a free operation over the acc elerometer reading, the pervasive transaction processing is no longer dependent on the view of accelerations. The above scenarios showcase the sema n tic power of our pervasive transaction model. With the operation and parameters defined, application progra mmers are able to specify both safety requirements and relaxations that are practical in pervasive computing environments. To enforce these requirements and utilize the relaxations, runtime protocols/mechanisms are needed. In the following section, we intr oduce the Context Lock protocol, a locking protocol that regulates the runtime transaction processing by utilizing the semantic power in our pervasive transaction model. Pervasive Transaction Programming Interface Programmers formulate pervasive transa ctions using the transaction interface, in which, operations tx_start() and tx_end() are provided to declare the start and end of a transaction. Programmers are also provided with a list of all available operations and operands. Programmers can compose the se operations between the tx_start() and

PAGE 111

111 tx_end() which will be assembled sequentially into a transaction at runtime according to the execution order of the program. The Context Lock Protocol The idea of locking context is two pronged: (A) isolation we hope to control the level of isolation among conflicting context operations (i.e. sensing and actuations) by issuing locks, and to provide a safer execution environment for concurrent pervasive transactions by separating conflicting transactions and lim iting interference from the physical world; (B) integrity we hope to maintain context within the prescribed context envelope by locking out risky operations on context entities. For each context entity in the space, if a lock can be assigned to protect i ts value from the impermissible range, then the entire pervasive space will conform to the overall integrity constraints, hence considered as safer. In this section, we introduce the concept of context lock, describe its elements and mechanism, and present a lock protocol that is proven to achieve the above two goals. Pervasive Isolation Semantics The issue of isolation has been well researched in conventional database systems. However, when translating this issue into the realm of pervasive computing, we n otice a semantic change in the notion of isolation. Hence many well established database theories and approaches addressing the issue of isolation are no longer suitable. In this section, we first provide three observations of pervasive transactions to ide ntify the semantics of isolation in pervasive computing. First, there exist common patterns for pervasive transactions. Most pervasive transactions are issued by pervasive applications and services, which share typical

PAGE 112

112 patterns when modeled by sensing (R) and actuation (W) operations. We observe four basic R W patterns that constitute many pervasive transactions: R which represents transactions with (one or many) sensing operations only. W which represents transactions with (one or many) actuations opera tions only. W R which represents transactions that use sensing to verify the effects of completed actuations. R W which represents transactions that use sensor readings to determine the next actuations operations. The above patterns represent four clas ses of pervasive application s with different requirements for isolation. For example, R type transactions are typical for most monitoring and surveillance services. A sensor reading only reflects the context observed at the time of sensing. Sensing is typi cally performed at a pre set pace. Previous senor readings do not affect the timing of the next sensing operations. R type transactions do not require exclusive accesses to read the target context entities. In fact, they are used for context monitoring bec ause other transactions and external factors may modify the context at any time. W pattern represents a class of less common transactions, which perform actuations only. A W type transaction could fail if a concurrent transaction also modifies the same con text entities with an inconsistent target value. W R pattern is common for applications that actively change the physical space through actuations (W), whose effects are then validated by sensor readings (R). Without isolating a W R transaction, conflictin g transactions and external events could interfere with the transaction, resulting in invalid effects of W. R W pattern represents a class of transactions that react to context changes. These transactions make decisions to actuate based on sensor readings. Interferences are considered most harmful to this type of transaction the decision of W could be based on an obsolete reading if the context entity is corrupted by interfering transactions and events between R and W. In

PAGE 113

113 summary, we observe the three typ ical patterns for pervasive transactions require distinct levels of isolation. While some transactions are open to concurrent executions, others may suffer from conflicting transactions and interfering events, which cause inadequate or even wrongful execut ions. Second, pervasive transactions need to embrace in accuracies Pervasive systems are inherently imprecise. Sensors produce readings within a certain accuracy and resolution. Actuators operate within limited precisions. Both sensing and actuations are performed in the physical space, a domain that is often dynamic, even volatile. Even if we have a pervasive system that perfectly isolates all conflicting transactions from each other, the interference from the physical world would still inevitably affect the result of these transactions. Moreover, many pervasive applications are mindful of these physical limitations, allowing room for inaccuracy in their executions. (For example, an electric oven service would accept temperature accuracy within 5 degrees. ) Hence, to manipulate and protect context in pervasive spaces with the same precision as we manage data in database systems, is not only impractical but also unnecessary. This inaccurate nature of pervasive space requires us to shift focus on the issue of isolation for pervasive transactions. We argue that the goal here is not to establish an exact and uniform isolation for all transactions, but to provide customized isolations for transactions, each exposing only to its own acceptable degree of conflicts and interferences. Third, conventional isolation levels are not suitable for pervasive transactions. Most database systems use popular isolation levels (such as UNCOMMITTED, COMMITTED, REPEATABLE, AND SERIALIZABLE) to control the behavior of

PAGE 114

114 transactions We find these well established isolation levels inadequate for pervasive a transaction reads data that has been modified by another transaction that later rolls back never roll back by design. Unlike database transactions which rollback to discard tentative changes, any updates of context by pervasive are directly materialized into the physic any change of data that create inconsistent views between two reads. However, by this standard, most read in pervasive transactions are non repeatable because sensor readings are subject to physical disturbance. A reasonable approach would be to relax the definition of context does not exceed a tolerated threshold. Also, instead of applying a uniform level of isolation, we should allow individual transaction to specify its own degree of tolerance. These observations lead us to rethink the semantics of isolation in the domain of pervasiv pervasive isolation is a property to protect the execution of a pervasive transaction from conflicts raised by concurrent transactions, as well as interference by external factors s uch as physical and human activities; (2) unlike database transaction which remains completely unaware of concurrent transactions during its execution, a pervasive transaction is mindful of potential conflicts and interference, and desires certain levels o f isolation to limit the effects of these conflicts and interference; (3) individual pervasive

PAGE 115

115 transaction can have distinct level of isolation depending on the purpose of the application. To address the need for pervasive isolation, we introduce a varia tion of lock concept, namely, the context lock. We first describe two basic types of context lock view lock and update lock, present their formal definitions, then introduce a lock management protocol for pervasive transactions. Context Lock Types In t his section, we introduce two lock types: view lock and update lock. A view lock isolates a transaction from other transactions and external events to ensure the quality of its reading. Based on the needs of different pervasive transaction patterns, we ske tch three view lock types: which indicates the lock owner (a transaction) does not want the context entity to change while holding the lock. is the most restrictive among all read lock types by excluding any context changes. which indicates the lock owner allows any change to the context entity while holding the lock. places no restrictions on concurrent transactions or external events and is most suitable for R type transactions (monitoring applications). which indicates the lock owner allows the c ontext entity to change within a certain degree while holding the lock. As a relaxed from of is purposed for context entities with continuous domains where disturbance of sensor readings are practically inevitable. An example of such context e ntity would be temperature. The above three view lock types cover the need for read protection by pervasive transactions in most scenarios. We present a formal definition of view lock in a generalized form below: Definition 8 11 View Lock. A view lock, protects the view of context entity e to be consistent to the owner of the lock (transaction T ). A view lock grants the

PAGE 116

116 read access to the lock owner. The view of e is considered consistent if e satisfies the constraint during the lifetime of view lock. When a transaction is granted a view lock over context entity e the lock ensures e specified threshold and are considered as special cases of the view lock where respectively. The view lock protects a context entity against incompatible concurrent transactions by denying write access. As previously discussed in Chapter 7, the difference between pervasive systems and database are apparent des pite of the similarities. As a result of these differences, the same strict isolation control in databases cannot be imposed on the pervasive transactions without proper relaxations. The parameters and defined previously provide several opportuniti es for relaxations on the writer side: First, the deviation relaxation threshold, accommodates the possibility for concurrent write operations if there exist a mutually acceptable range of intended context for these writes. Second, the temporal relaxat ion window, enables a large class of write operations that actuate through interactions with the physical environment or human. The completion of such write operation takes longer time than the actuation of the physical device alone, which requires lon ger isolation protection provided by context locks. Third, the durability relaxation window, relaxes the requirement of permanent durability (which is rarely intended in pervasive spaces) to temporary durability in a timed window, which is achievable t hrough monitoring after the completion of write. Supporting this feature requires augmentation of the semantics of update locks to utilize the same monitoring service used by view locks. In this section, we present our update lock definition that impleme nts the above relaxations.

PAGE 117

117 Definition 8 12 Update Lock. A update lock, is assigned over a write operation to ensure the following: constraint: shares concurrent access with another operation only if they are mutually compat ible (as defined in Definition 8 11). constraint : The post actuation context margin of deviation) before window expires. Otherwise, the update lock will be revoked, the owner transaction aborted. constraint: The post actuation context argin requirement: i.e., throughout window. Otherwise, the update lock will be revoked, the owner transaction aborted. For the purpose of simplicity, we use the shorthand notation to represent an update lock in this document parameters and appear in our notations only when they are relevant to the discussion. An update lock provides the necessary isolation to ensure that the protected write operation achieves the target context and maintains its durability withi n the desired time windows. Once a transaction acquires an update lock, it has both read and write accesses to the locked context entity. As definition 7 10 suggests, update locks are not necessarily exclusive. A transaction may share its access to a conte xt entity with other transactions as long as their operations over are mutually compatible. We define the compatibility of operations as follows. Definition 8 13 Compatibility of Operations. The compatibility among all operation types are defined as following : A free operation i s compatible with any operation ; A read operation, is compatible with any operation except a write operation whose projected post actuation context could violate the constraint, i.e. a

PAGE 118

118 write operation is compatible with only if is the current value of Two write operations and are compatible only if their margins are mutually satisfied, i.e. and The full compatibility ma trix is presented in the Table 8 2 as a summary of the above definition. Note that compatibility is determined entirely by the operation types and t heir parameters. The role of the above compatibility matrix is to determine the compatibility among operations and their corresponding locks so that processing incompatible operations is disallowed. However, enforcing compatibility only partially fulfills AI 2 D, leaving a greater role for the context lock protocol (next section) to ensure AI 2 D. The Protocol The context lock protocol contains the following policies: Policy 1. A transaction must obtain a view lock to read, and a n update lock to write; Policy 2. To obtain an update lock, a transaction can only upgrade it from a view lock; Policy 3. A transaction can release a view lock over if there are no more operations in to be processed that are dependent on the view of (either as indicated explicitly by an operation, or by reaching at the end of ), in other words, in order to perform an operation must possess the view locks over the context entities which is dependent on; Policy 4. A transaction can degrade an update lock into a view lock after write, but cannot directly release an update lock; Policy 5. A transaction succeeds to obtain a lock over only if the requested lock is compatible with all locks in effect over ; Policy 6. If transaction does not succeed to obtain a lock, it will be aborted. For operation over context entity we denote four different types of lock o perations : : obtain a view lock;

PAGE 119

119 : release a v iew lock; : upgrade a vi ew lock into an update lock; : degrade an update lock into a view lock. Proof of Correctness First, we present the formal definition of a few concepts to be used in our proof. Definition 8 14 History When a set o f transactions execute concurrently, their operations may be interleaved. Also, these operations may interleave with external events. We model such execution by a structure called a history Each operation receives a timestamp: which marks the processing time of the operation. A history over a set of transactions { } stores timestamps of all operations in the transaction set, denoted as: is a history over where is a transaction, and is an operation of Definition 8 15 Conflict In a history two operations and from two transactions and are in conflict if (1) they are incompatible, or ( 2) is view dependent on if Definition 8 16 Conflict Equivalence of Histories We define two histories and to be equivalent ( ) iff. : they are defined over the same set o f transactions and have the s ame operations, they order conflicting operations of committed transactions (and external events) in the same way. Defini tion 8 17 Correctness of a history set A history set is correct if for each history either or is conflict equ ivalent to a 2PL history, i.e., we can transform into such that And in such transformation, no pair of conflicting operations will be re ordered.

PAGE 120

120 Definition 8 18 Early Release We define early releases over two types of context locks: Early release of a view lock : in history for any transaction if there exist operations and in ( and are context entities), such that or then there is an early release of a view lock. Early release of a update lock : in history for any transaction if there exist operations and in such that or then there is an early release of an update lock. Now we start our proof of the context lock protocol. Given a set of transactions, the class of histories generated by our context locking protocol is denoted as We divide this class into two subclasses: where: = { | there exists at least one early release of some context lock in history } = { | there does not exist any early release of any context lock in history } To prove the correctness of we show correctness of respectively. Correctness of H 1 We consider two cases: Case 1. There are only early releases of view locks in Given by definition, we can find operations and in such that or Case 1.1. If there does not exist an operation from another transaction such that (or ), th en the early release of does not affect other transactions. We can swap and (or ) without changing the order of any operations in history We can keep swapping such

PAGE 121

121 early release pairs of lock operations until ther e are no more early releases in the history. The resulting history Case 1.2. If there exists an operation from another transaction that (or ), we can prove that does not affect (Proof: according to context locking protocol (Policy 3), is not dependent on the view of Because is an operation over it could only affect the view of Therefor e does not affect .) The processing of is oblivious to i.e. as if does not exist, which is same as in Case 1.1. Case 2. There are early releases of update locks in Given by defi nition, we can find operations and in such that or Case 2.1. There does not exist a lock release operation such that (or ). Case 2.1.1 There does not exist an operation from another transaction such that (or ). Similar to Case 1.1, we can transform into such that without changing ordering of any operations in Case 2.1. 2. There exists an operation from another transaction such that (or ). We can show does not affect : operation is either dependent or independent on the view of If independent, then the processing of is oblivious to similar to Case 1.2; if dependent, we can show does not affect the view of : since there is no lock

PAGE 122

122 release such that (or ), must pos sess a view lock over when is processed, according to the locking protocol does not affect the view of (otherwise a lock will not granted to ). Because does not affect the view of does no t affect Case 2.2. There exists a lock release operation such that (or ). Case 2.2 .1 There does not exist an operation from another tr ansaction such that (or ). Similar to Case 1.1, we can transform into such that without changing ordering of any operations in Case 2.1. 2. There e xists an operation from another transaction such that We can show does not affect : is possessing a view lock over when is proces sed, according to the locking protocol, does not affect the view of (otherwise a lock will not granted to ). Because does not affect the view of does not affect Case 2.1. 3. There exists an operation such that (or ). Then does not affect see Case 1.2. Correctness of H 2 We prove by contradiction. Suppose the re exists a history Then there exist operations and such that one of the following is satisfied: or, or

PAGE 123

123 or, In either case, by definition, we have an early release in Therefore a contradiction. Pervasive Transaction Management Architecture Architecture Overview In this section, we present the pervasive transaction management a rchitecture, which provides a reference design to support our proposed pervasive transaction model and the context lock protocol. The overview of the archi tecture is presented in Figure 8 4 The core of the transaction management architecture is highlighte d in grey, which includes the following five modules: Transaction Pool : a structure that manages and stores the pervasive transactions submitted by the applications; Transaction Processor : the processing engine that oversees the lifetime of each transactio n by requesting/releasing context locks, executing operations, and committing/ aborting a transaction. Context Lock Manager : the management component that responds to all context lock requests submitted by the transaction processor; Context Map : a struc ture that maintains all the context entities the operands of pervasive transactions; Context Monitor : a component that provides monitoring services over context entities to detect violations of context constraints subscribed by context locks. In the r emainder of this section, we present the design of each module in detail and introduce the interfaces for inter module interactions. We will also present the key algorithms designs for selected modules. A full data structure design of the pervasive transac tion processor written in Java is presented in Appendix D. Transaction Pool Function The transaction pool provides a structure that stores all the pervasive transactions submitted by applications that are ready for or undergoing processing.

PAGE 124

124 Applications can submit pervasive transaction requests to the transaction pool. Once a transaction is admitted into the pool, a pervasive transaction structure ( instance ) is created, which opens spaces for storing critical transaction information such as operation sequ ence and the runtime status. The transaction scheduler determines the order of processing among these transactions by employing multiple alternative scheduling strategies such as FIFO Round Robin and SJF Components Key components of the transaction pool including the following: Transaction Pool Manager, which manages the life cycle of pervasive transactions. Applications can submit/update a transaction request to the transaction pool through the transaction pool manager. Once a transaction is admitte d into the pool, the pool manager will monitor its runtime status. It will notify the corresponding application on the commit or abort of a transaction, and exit the transaction from the pool. The transaction pool manager is also responsible for validating transaction requests by checking the parameters and sequences of the operations issued. For example, it will invalidate the request to issue a read/write operation over e if e is previously freed by the same transaction. Transaction Scheduler, which dete rmines the order among the transactions in the pool for the Transaction Processer. Multiple scheduling strategies could be implemented in the scheduler. As a baseline implementation, we propose to use the Round Robin algorithm to maximize the concurrency a mong transactions. Pervasive Transaction Instance, which assigns memory spaces that store transaction information needed for processing. In each transaction instance, the operation sequence for the transaction (read, write and free) is stored. For each tr ansaction, it also stores the submission status (e.g. whether an application has started a transaction by tx_start() or closed the transaction by tx_end() ), and processing status (e.g. the index of the next operation in the sequence to be processed). Int erface The transaction pool provides the following two interfaces: Interface toward applications. Applications can utilize the pervasive transaction interface (see Chapter I.) to customize, assemble and submit transactions to the transaction pool manager At runtime, an application requests the transaction pool to assign a new transaction instance through tx_start (). The application can continue to update the transaction by appending (read, write or free) operations to the instance, until it closes the t ransaction with tx_end() which means the operation sequence of the transaction instance is finalized.

PAGE 125

125 Interface toward transaction processor. The transaction processor retrieves transaction instances from the pool one at a time through the getNextTransa ction() interface provided by Transaction Scheduler. The content of the transaction instance is completely visible to the transaction processor. Once the processor retrieves an instance, it checks to runtime status to find the first operation in the sequen ce that has not been processed, then requests the necessary locks needed to perform the operation. If the locks are granted, it executes the operation and updates the runtime status of transaction. Then it continues to retrieve the next transaction to be p rocessed from the scheduler. Key Structures/Algorithms An important aspect of the transaction pool design is the data structure that stores all the pervasive transaction instances in the pool. While there are many options available, the optimal structu re is largely dependent on the scheduling strategy to be employed. As a baseline implementation, we propose to use a linked list as the container of all transaction instances. Transaction Processor Function The transaction processor is the key module of the entire pervasive transaction management architecture. It is responsible for issuing lock requests, processing read/write operations, and committing or aborting transactions. The transaction processor handles one operation at a time within what we cal l a transaction cycle. At the start of the cycle, the processor retrieves the transaction to be processed for the scheduler. It identifies the next operation to be executed in the transaction. It then looks up the lock table in the context map to determine if any lock (obtain/upgrade) action is need to perform the operation. If that is the case, it issues a lock request to the context lock manager. Once the lock request is granted, it process the operation by performing read or writes to the corresponding c ontext entity stored in the context map. After the operation is successfully processed, it enacts the lock

PAGE 126

126 scheduler again to see if any lock degrade/release action can be performed. Finally it updates the runtime status in the transaction instance and fin ishes a transaction cycle. Components The transaction processor consists of the following key components: Lock Scheduler which determines and performs lock request/release actions pre/post operation processing. Operation Processor, which performs read /write operations over context entities stored in the context map. Abort Manager, which identifies situations where abort is needed and perform the fail safe abort. Commit Manager, which performs the transaction commit. Interface The transaction pool pro vides the following two interfaces: Interface toward Context Lock Manager. The transaction processor interacts with the context lock manager through the lock scheduler by exchanging lock request/response messages. Interface toward Context Map. The transa ction processor processes transactions operations over context entities, which are stored in the context map. We will present the structure of the context map and explain the interactions between the context map and the transaction processor in the followi ng section. Context Lock Manager Function. The context lock manager responds to lock requests from the transaction processor. It enforces the context lock protocol by ensuring that (1) co existing context locks are always compatible with each other (throug h Compatibility Tester); and (2) when a lock constraint (such as constraint and constraint ) is violated, its corresponding lock will be invalidated. In addition, the context lock manager also detects and handles deadlocks. Components Key components of the context lock manager include the following:

PAGE 127

127 Deadlock Detector, which detects the deadlock situations by analyzing the wait for graph for transactions. Compatibility Tester, which checks if a requested lock is compatible with all context locks in effect. Interface The context lock manager is dependent on the context monitor module, which provides monitoring services over constraint s and constraint s. When the monitor detects a violation of the constraint, it notifies the context lock manager by invoking onViolation () interface. The context lock manager reacts to such violation by revoking the corresponding context loc k, which potentially results in a transaction abort in the transaction processor. Context Map Function The context map stores all the operands of pervasive transactions context entities. For each context entity, a structure (instance) is created to sto re information related to the context entity. Safety Transaction Mechanism Safety transactions are a class of transactions initiated by the pervasive system to maneuver context within the context envelope by issuing sensing and actuation operations. The g oal of safety transactions is to enable a more intelligent and autonomous pervasive system in face of impermissible and risky situations. When context is escaping from the desired envelope, safety transaction is expected to enact proper sequences of actuations to counter the erroneous context, restore and stabilizes the desired context. Safety transaction is a best effort mechanism. Limited by the sensing and actuation capabilities of the system, safety transaction does not guarantee the elimination o f all safety risks, but only provides additional protection during risky scenarios.

PAGE 128

128 In this section, we first present the definitions of safety transaction and its elements. Then we describe an algorithm to safety transaction composition. In Chapter 5, w e defined that sensing and actuation operations in the above definitions are logical operations. The definitions describe the logical effects of these operations within the context space. While the link between physical sensors and logical sensing operatio n is obvious, the link between logical actuation into the physical domain, however, is not necessarily trivial. Take a logical actuation w ( e, d ) for example, there maybe none, exactly one, or multiple actuator devices available to perform w ( e, d ) in the ph ysical space. In addition, by performing operation w ( e, d ), an actuator device affecting context entities other than e in a way may or may not known to the system. Therefore, translation between logical actuations and phy sical operations requires a proper actuator model to be established first [ Def. 1 ]. Revisiting Actuator s 1.1 Actuator The pervasive system has a set of available actuator devices A = { a i }. An actuator a is defined by a parameter space P a = { p | p is an a cceptable parameter combination for actuator a }. 1.2 Trace of Actuation To better understand the effect of actuations, a pervasive system keeps a record of the contextual traces for each executed actuation. The trace of an actuation w is defined as a six tuple: trace w = ( a p c start c end t start t end ), where a is the actuator device that performs the actuation, p is the parameter combination assigned to the device, c start and c end are the context at the start and end of execution respectively, and t sta rt and t end are timestamps of c start and c end respectively. We show how t end is determined in the context lock protocol.

PAGE 129

129 Problem Formulation Safety transaction has the same formal structure as any pervasive transaction. It consists of a number of sensing a nd actuation operations; and it is managed by the same transaction processing engine. Safety transactions receive higher priorities in lock acquisition. A context lock granted a pervasive transaction will revoked if it is requested by a safety transaction. One question remaining, however, is that how to find the suitable and most effective sequences of operations to fulfill the goal of risk mitigation. We formulate the problem of safety transaction composition into two sub problems. Problem A. Composing sa fety transaction with logical operations For context space C P given context envelope and current context c compose a safety transaction ST = {{ w i r j }, <} that pulls current context c into the envelope, i.e. find ST : c such that Problem B. Translating from logical to physical operations Given a logical actuation w ( e d ), current context c and actuation trace set TR = { trace i }, find the most appropriate actuator a A with parameter p P a that changes the value of e to d In the next t wo sub sections, we propose two algorithms to solve each of the above sub problems. Algorithm A. Composing safety transaction using logical operations We present a procedure for proble m A in pseudo code in Figure 8 5 To analyze the algorithm, we describe two technical details in Procedure A. Distance function A natural measure of distance between two context points context space uses context entity values, i.e. sensor readings as scalar s this geometric distance is not necessarily a good metric to measure the effort of context transformations,

PAGE 130

130 which are accomplished by actuators instead of sensors For example, two context points may have a close sensing distance but a long actuation dis tance because the actuator takes very long time to achieve such context transform. This observation inspires us to improve the algorithm by using actuation based distance functions. Pureness of actuations The success of the above algorithm relies on one a ssumption: for any actuation w ( e, d ) contained in the result ST an actuator always exists to perform w ( e, d it will not affect any context entities other than e This assumption is often not realistic. To fix actuator selection discussed in problem B, and improve procedure A by using multiple loops to approximate target envelope, if a direct actuation is not possible. Algorithm B. Trans lating from logical to logical operations We present a procedure for prob lem B in pseudo code in Figure 8 6 Algorithm B relies on the observation that most actuations produces repeatable effects if an actuation causes a change over a certain context ent ity, repeating the same actuation is likely to produce the same context change. This inspires us to delve into the history of actuation traces and utilize existing knowledge to find the appropriate actuations. To limit the side effects of a physical actuat ion, we use cross products in the process of actuation selection, denoted as Smaller indicates lower side effects over other context entities. We use execution time t as the cost of actuation for the final actuation selection. The lower t the fast er the actuation achieves the desired context, the more efficient the safety transaction is. Utilizing the previously discussed heuristics, we present the procedure for overall safety tra nsaction composition in Figure 8 7

PAGE 131

131 Limitations of Safety Transaction s The safety transaction mechanism is most effective in pervasive spaces with actuators to correct faulty context observable to its sensors; on the other hand, sensors are responsible to monitor the effect of actuations and ensure the safety and correctness of their executions. We say a pair of sensor and actuator is symmetric if they access and modify a shared set of context entities. Clearly, the more symmetric sensor actu ator pairs there are in the pervasive space, the more powerful the safety transaction mechanism is. However existing pervasive systems typically have greater sensing power than actuation, which limits the possibilities for safety transaction composition utilizing existing knowledge of sensor and actuator operations, can only suggest a safety transaction that is mostly like to work. However, there is no guarantee of the effect iveness of safety transaction, because the affects of some actuations may not be repeatable. In critical and severe safety conditions, specific human knowledge and knowledge. The best application for safety transaction therefore is for maintaining safe and desired context, rather than averting severe and extreme context.

PAGE 132

132 Table 8 1. State transition rules of pervasive transaction processing State Transition Condition / Action Pai r Description init soa PT / The initialized transaction is treated as a pervasive transaction (PT). soa exec LCK_REQ / LCK_GRT A pervasive transaction proceeds to exec state if the requested locks are granted. soa fsa LCK_REQ / LCK_REJ A trans action proceeds to fsa state if a lock request is rejected. soa pcmt TR_CMPLT / If all operations of a transaction have completed execution, the transaction proceeds to pcmt state. exec soa EXEC_S / LCK_RLS A transaction releases the context locks and returns to soa state if the execution of the current operation succeeds. exec fsa EXEC_F / TR_ABRT A transaction proceeds to fsa state if the execution of the current operation fails. LCK_RVK / TR_ABRT A transaction is forced to fsa state if it s possessed context lock has been revoked. pcmt cmt WAIT
PAGE 133

133 Figure 8 1. The s tate diagram of a pervasive transaction.

PAGE 134

134 Procedure PRE_CMT (T i ) 1. condition = WAIT ( TO ); 2. if condition WAIT
PAGE 135

135 Procedure TR_ABRT (T i condition) 1. switch condition 2. case condition EXEC_F LCK_RVK 3. goto step 8; 4. case condition LCK_REJ 5. goto step 15; 6. case condition WAIT=TO 7. goto step 17; 8. for each op in T i operati ons AND op is in execution, 9. stop operation op by sending a STOP signal to the device (if possible); 10. for each e in E P 11. execute r ( e ) 12. update current context: c = ( r ( e 1 ) r ( e 2 ) r ( e n )); 12. if c // T is the overall system wide context envelope 13. invoke ST : c ; 14. for each L in L 15. LCK_RLS ( L T i ); 16. update global context envelope = i // i is the target envelope for transaction T i ; 17. T i FAIL_SAFE_ABORT 18. Q .dequeue ( T i ); End Figure 8 3. Procedure of fail safe abort ( TR_ABORT ).

PAGE 136

136 Figure 8 4 The Pervasive Transaction Management Architecture

PAGE 137

137 Procedure A 1. Initialize ST = ; 2. For each context entity e E P 3. project c on dimension e, the projection denoted as c | e ; 4. project on dimension e the projection denoted as | e ; 5. if c | e | e go to step 2; 6. find d | e such that the distance function dist ( c | e d ) returns the minimal; 7. append w ( e, d ) to ST ; Return ST Figure 8 5. Algorithm for composing safety transaction with logical operation s. Procedure B 1. query TR based on start and end context, and store result traces in H : H = { trace i | c start | e = c | e c end | e = d } TR c | e denotes the projection of c on e ; 2. if H = go to step 8; 3. for each trace H 4. compute cross product = < c start c end > e / |< c start c end >|, e is the unit vector of domain e ; 5. if > remove the trace from H is a pre defined threshold; 6. for each trace H compute t = t end t start ; 7. find trace i with the lowest t i ; 8. return ( a p ) of trace i 9. r eturn MESSAGE (no actuator available). End Figure 8 6. Algorithm for translating logical to physical operations.

PAGE 138

138 Procedure SAFETY_TR_COMPOSE 1. Initialize ST = ; 2. for each context entity e E P append r ( e ) to ST ; 3. execute ST to derive current context c ; 4. init ial_distance = min{dist( c )}; 5. call Procedure A; 6. for each w in ST 7. call Procedure B; 8. if Procedure B returns error, abort ST ; 9. else execute actuation on actuator a with parameter p ; 10. for each context entity e E P append r ( e ) to ST ; 11. execute ST to derive current context c ; 12. distance = min{dist( c )}; 13. if distance = 0, commit ST ; 14. else if distance < initial_distance go to step 5; 15. else abort ST ; 16. end. End Figure 8 7. Improved algorithm combining Procedure A and B.

PAGE 139

139 CHAP TER 9 PERFORMANCE EVALUATI ON Approach In this chapter we examine and quantify the performance of the context lock protocol and several of the associated pervasive transaction concepts. To this end, an experimental approach based on event driven simulation and benchmarking has been attempted. However, design ing a pervasive transaction / smart space benchmark proved to be quite challenging. This is mainly due to the lack of data describing pervasive transactions a novel concept that is yet to be establishe d. Consecutively, synthesizing a benchmark for the simulator was an extremely challenging task. In response, we adopted an alternative analytic approach to performance modeling and evaluation. The analytic models allowed us to zoom in on the critical aspec ts and conditions of a smart space running pervasive transactions. Specifically, we zoomed in on the probabilistic aspects of contention as well as relaxation opportunities (e.g., Free operation, and ). We present two analyses in this chapter. In Analysis 1, we examine the effects and inter relationships of the Free, operations, under invariant conditions of and In Analysis 2, we examine the opposite scenario the effects and inter relationships of and under invariant conditions for Free, The division of the analysis into two parts was necessary to reduce the dimensionality of the problem. Analysis 1 Free, and Analysis Objective Analyzing the effect of { Free, } on the overall pervasive transaction processing under the context lock protocol. The main performance metric we sought is the

PAGE 140

140 probability to abort A meritorious effect of any of the {Free, } is one that can be measured as a decli ne in and vice versa. We follow the notation scheme introduced in [45 ]. Assumptions: Single transaction class. All transactions can be characterized by the same profile (including the mean length of transaction probability distribution of access pattern, write (or read) ratio, and free, and characteristics ). No external events. We only consider aborts induced by incompatible lock requests (contentions) in Analysis 1. Transaction arrival rate The co mbined arrival of new and restarted (due to abort) transactions is characterized by Computation time overhead and lock acquisition/release time overhead are negligible. We only consider the processing time, i.e., time to read (sense) and time to write (actuate). Transaction Model The following are parameters that characterize pe rvasive transactions in this analysis: transaction arrival rate access matrix where is the total number of context entities in the space, and is the mean length of pervasive transactions (i.e., number of read and write opera tions, excluding free, in a transaction). represents the probability that the operation of the transaction accesses (through read or write) the context entity. ( resp ) is the probability that an operation of the transact ion (again, excluding Free ) is a write ( resp read). mean distance to free is a parameter designed to characterize the occurrence of Free operations. is defined by the average number of operations between an (read or write) access over a context en tity and the free of the same context entity (either explicitly by a free operation or inexplicitly by reaching the end of transaction. mean time to read: and mean time to write ( window included), clarify what dis tribution we are assuming. Lock Holding Time The lock holding time for the access to at the operation of a give transaction starts from processing the operation and ends when the lock is released. Because

PAGE 141

141 the lock protocol prohibits transaction waiting for a lock, and we omit the lock acquisition and release overhead (insignificant compared to operation execution time), the lock holding time is essentially the total operation execution time between the operation and the lock release: (9 1) where is probability that the operation of the transaction is a write. Using a universal write probability can be further reduced to: (9 2) where is the mean processing time per operation and We know that the probability to access at the step is Hence, the average lo ck holding time for context entity per access is (9 3) Probability of Read or Write The arrival rate of read accesses towards is (9 4) while for writ e access, we have (9 5) The probability that an incoming access request towards is a read and write request, respectively, is and (9 6)

PAGE 142

142 Probability of Contention When a read access occurs towards a contention is raised if is locked by at least one incompatible update lock. The probability that there exists one update lock is (9 7) The probability that an update lock and a read access conflicts, denoted as is dependent on the distribution of and When a write access occurs towards a contention is raised if is locked by at least one incompatible update or view lock. The probability that there exist s one update lock is derived in Equation 9 7 The probability that an update lock and a write access conflicts, denoted as is dependent o n the distribution of The probability that there exists one view lock is (9 8) The probability that a view lock and a write access conflicts, denoted as is the same as i.e., The contention probabilities for a read and write access towards respectively, are and (9 9) Uniform based Derivation of and : Assuming 1. each context entity has a continuous domain normalized to [0,1]; 2. the distribution of target value of write in such domain is uniform; and 3. is

PAGE 143

143 the normalized percentage, and is a constant for all writes (for simplicity). We can evaluate as the probability that two random variables, and do not satisfy: and i.e., (9 10) : The probability of a read and write contention can be evaluated by the probability that the constratin is violated (i.e. given the target value of write and the current of value at the lock request the condition that is not true ). (9 11) The above derivation of and is based on the assumptions that distributions of both and are uniform. However, in certain scenarios, we find Gaussian distributions may be more realistic. For example, when a context entity represents a physical aspect (such as temperature or humidity), it is often observed that its values can be fitted by G aussian distributions. In the following section, we show an alternative derivation of and based on Gaussian distribution. Gaussian based Derivation of and In order to apply Gaussian distribution, we normalize the dom ain of each context entity into an infinite interval We assume two Gaussian distributions on random variables and denoted by and respectively. We derive and as fol lows: : We know that

PAGE 144

144 (9 12) where is the cumulative distribution function (CDF) of the standard normal distribution, : We know that (9 13) Probability to Abort For the operation in a transaction, the probability that such operation completes successfully (i.e. free of contention) is (9 14) Probability for a transaction to commit is the probability of contention free access for all its operations (read or write), and can be evaluated through: (9 15)

PAGE 145

145 Mean Transaction Lifetime The probability for a transaction to survive exactly operations ( ), denoted by a function of : can be derived as: (9 16) Here, the lifetime of a transaction, can be described by the number of completed operations before it aborts (or commits). Mean transaction lifetime, denoted as can be derived as: (9 17) Revisi ting Loc k Holding T ime The original model only considers lock release (either by commit or free operation) as the end of lock holding time. Now we take lock revoke (by an abort) into consideration to compute the mean lock holding time. + (9 18) where and is the probability that the transaction aborts at th operation, when it requests a lock for its th operation, and is the probability that the tr ansaction successfully completes its th operation, when it requests a lock for its th operation (in other words, the probability of successful completion between its th and th operations).

PAGE 146

146 (9 19) (9 20) Numerical Resolution We can solve the above model using an iterative procedure. Once assigni ng values to input parameters, the other model parameters can be evaluated via the provided equations, using the results as the input f or the next iteration. The desired computational accuracy can be fixed by defining a value specifying the maximum difference between values obtained by two consecutive iterations (e.g. if is the abort probability at iteration then w e stop the evaluation when is true). We have empirically observed that it always converges in a few iterations. Results We evaluate the numerical results of our analytical model using the configurations summarized in Table 9 1. The listed parameters are assigned with the default valued given in Table 9 1, unless otherwise specified. We observe decreases in with the introduction of free operations (Figure 9 1). We use the parameter as a metric for t he involvement of free operations. When all locks will be released at the end of the transaction (i.e., no free operations involved), the behavior of our context lock protocol becomes the same as a strict 2 phase locking protocol. As decreases (i.e., increased involvement of free operations), the mean lock holding time also decreases, resulting in a lowered probability to abort. In the extreme case where all locks will be released

PAGE 147

147 immediately after the operation completes, resulting in the lowest probability to abort, as indicated by the blue curve in Figure 9 1. The effect of is shown in Figure 9 2. In general, we observe that the probability to abort decreases, as increases. However, we can no longer observe this effect when For example, as shown in Figure 9 2, the blue curve ( ) and the green curve ( ) completely coincide. This can be explained by the relaxation mechanism enabled by Such relaxation reduces the abort rate by exploiting the opportunity to reduce the probability of read write contentions (i.e., ). As Equations 9 12 and 9 14 suggest, is a function of and When Hence, will not be reduced. The effect of is shown in Figure 9 2. We find that the effect of is too trivial to be observed when This is because of the dominance of read operations in our experiment (write ratio ) With a low write ratio, the majority of the contentions will be between read and write, whose prob ability of conflict is always 1 (i.e., ) when as explained previously. As a result, the relaxation effect enabled by on write write contentions (i.e., ) is insignificant. That explains why the red curve ( ) and the light gr een curve ( ) nearly coincide in Figure 9 3 However, with an increased write ratio (as shown in Figure 9 4 ), we will able to separate these curves as the relaxation effect enabled by becomes more significant as the write write contentions become mor e frequent. Notice that the high write ratio also results in a more drastic increase in in Figure 9 4 exceeds 0.9 when reaches 0.1 for all four curves.

PAGE 148

14 8 When the probability of read write conflict decreases as decreases. Although a lower yields a higher the overall probability to abort is decreased because of the read dominance in our experiment. That explains why the lowest produced the lowest (the blue curve with ) in Fi gur e 9 3 We show the compound effect of and in Figure 9 5 In this experiment, we use a fixed : ratio ( ). When and as indicated by the blue curve in the figure, no relaxation (on and ) is used, resulting in the highest As (and accordingly ) increases, we observe that decreases. As increases, the four curves start to converge. We observe the maximum performance gain when is at the interval [0.25, 0.75]. Analysis 2 and Analysis Object iv e Based on the model established in the previous analysis, we further analyze the effect of { } in the context lock protocol. Again, we use the probability to abort as a metric to evaluate the effect of and Probability of a Write Success For a specific write, its write time can be modeled as: where represents the actuation time of the device, is a random variable representing the waiting time to attain the desired context after the device actuation, and is the durability window (the time to protect the attained context to be durable). By the definitions of and we know that

PAGE 149

149 We use another random variable to represent the actual time needed to attain the desired context. Notice that is not bo unded by when it means that window expires before the completion, which leads to an abort of the transaction according to the context lock protocol. We assume the distribution of to be log normal on a semi infinite interval which has been successfully fitted to empirical reaction times [ 44 ]. We denote such distribution by: For a write access towards after its update lock is obtained, the probability of its success is determined by the probabilities of two independent events (assuming the actuator device is failure free): attaining the desired context within window ( completion ), and persisting the attained context through window ( durability ). We denote the probability of completion as and the probability of durability as The probability of success for a write is: Probability of Completion (9 21) where is the CDF of the standard normal distribution defined previously. Mean Time to Completion (9 22) After some algebra, we have (9 23) where is the error function of normal distribution defined by

PAGE 150

150 (9 24) Probability of Durability The durability constraint will be violated if a random event takes place that changes the atta ined context during the window. To model the occurrence of this event, a random variable is defined as the time interval between attaining a desired context (at the end of completion stage) and the occurrence of the event tha t corrupts the attained context. Similar to the distribution of we assume that also conforms to a log normal distribution: Hence, the probabili ty that durability is sustained during the window can be evaluated as the probability of We derive as following: (9 25) The length of window is a constant, i.e., according to the lock protocol. Hence its corresponding mean value, is also Updating Transaction Model with and Based on the new variables and derived above, we update the transaction model established in Analysis 1. We first update (mean time to write): (9 26) Then we update (the probability that the operation in a transaction completes successfully). In the case of write operation, the probability of its success is determined by both two independent conditions: ( 1) free of lock contention, and (2) successful execution (i.e., surviving both and windows). The probability of condition

PAGE 151

151 (1) is already derived as And the probability of condition (2) is defined by We plug in and update the derivation of (9 27) Using the updated Equation s 9 27 and 9 28 we can analyze the effects of and by evaluating (the probability to abort) under different values for and parameters. Results Employing the same numerical resolution approach as in Analysis 1, we evaluate the effect of { } i n the analytical model. The effect of is shown in Figure 9 6 In this experiment, to focus on ly on the effect of we assume a write operation always survives its window (i.e., ). The value of affects two important variables: (1) the pr obability of completion for a write operation (i.e., ), and (2) the mean time for a write operation (i.e., ). As increases, its implication is mixed increases with which leads to a lower and also increases with which leads to a higher When is relatively low, the effect of is more dominant than the effect of That explains why higher yields to lower w hen is close to 0, as indicate d by the left part of Figure 9 6 When is high, the performance penalty (in terms of abort ratio) caused by large overwhelms the performance gains by high As a result, curves with high er cross over the ones with lower as shown in the right part of Figure 9 6 The effect of is shown in Figure 9 7 In this experiment, to focus only on the effect of we assume a write operation always survives its window (i.e., ) and

PAGE 152

152 we further assume the mean to completion is a constant (i.e., ) We observe that as increases, also increases This is because the increase in would cause both the probability of completion for a write oper ation (i.e., ), and the mean time for a write operation (i.e., ) to increase, resulting in a higher overall abort rate observed. We show the compound effect of and in Figure 9 8 In this experiment, we use a fixed : ratio ( )

PAGE 153

153 Table 9 1. Input Configurations Parameter(s) Meaning Default value Mean length of pervasive transactions 10 Total number of context entities 10 Access matrix A uniform matrix with each element Universal write ratio 0.05 Mean time to read 1 Mean time to write (for Analysis 1 only) 10 Mean time for device actuation (for Analysis 2 only) 2 Distribution of target value Distribution of current value Distribution of Distribution of

PAGE 154

154 Figure 9 1 Effect of Free Operations on the probability to abort We show under four different values for (mean distance to free). In this experiment, Figure 9 2 Effect of relaxation parameter on the probability to abort We show under four different values for In this experiment,

PAGE 155

155 Figure 9 3 Effect of relaxation parameter on the probability to abort We show under four different values for In this experiment, Figure 9 4 Effect of relaxation parameter on the probability to abort under a high write ratio. We show under four different values for In this experiment,

PAGE 156

156 Figure 9 5 Compound effect of and We show under four different combinations for ( ) values. In this experiment, Figure 9 6 Effect of on the probability to abort We show under four different values for In this experiment,

PAGE 157

157 Figure 9 7 Effect of on the probability to abort We show under four different valu es for In this experiment, Figure 9 8 Compound effects of and on the probability to abort We show under four different combinations for ( ) values. In thi s experiment,

PAGE 158

158 CHAPTER 10 CONCLUSION As computing permeates the physical world through sensors and actuator devices, the consequence of logical errors also extend s to the physical realm and creates real safety risks in our everyday li fe Traditional safety engineering approach fell short as it lacks the power and flexibility to meet a broad spectrum of safety demand in an open and constantly evolving computing environment. This research presents a safety oriented programming model, tai lored specifically to address the safety challenges in pervasive spaces. The first challenge is to make pervasive systems understand safety. Hardcoded rules and policies assume fixed risk scenario and hence may become stale as use cases change in perv asive environments. In addition, embedding these rules and polices into various software/hardware artifacts creates a fragmentation of safety knowledge, which may lead to conflicts and uncertainties in the overall system behavior. This research aims to con struct a uniform and integrated safety knowledge base, by enabling domain experts, in addition to programmers, to specify safety knowledge and concerns using a domain independent ontology for safety, we call DiOS. We presented the ontology design of DiOS i n Chapter 5, and a case study of DiOS used in Device Description Language (DDL) in Chapter 6, which demonstrated a path to an integrated safety knowledge base by extending domain specific languages such as DDL with DiOS to facilitate specification of safet y constraints for domain experts across application domains. Once all safety constraints are established in an integrated knowledge base, a challenge follows in that these safety constraints need to be enforced at system

PAGE 159

159 runtime. To formalize the runtime c yber physical interactions in pervasive systems, we presented pervasive transaction, a novel concept core to our programming model. We demonstrated in our model that the safety criteria can be formalized into a set of runtime properties for transaction pro cessing known as AI 2 D (Chapter 7). To deliver assurance to AI 2 D safety, we presented a context lock protocol, which utilizes lock concepts to protect critical context, and to isolate conflicting pervasive transactions. A proof is presented in Chapter 8 tha t the context lock protocol always produces a safe transaction processing schedule that meets the AI 2 D criteria. Finally, we evaluated the performance of our safety approach in Chapter 9. Safety can only be achieved at a cost. A cost benefit analysis is im portant to identify the optimal safety strategy We used transaction abort probability, as a key metric in our analysis, and established a probabilistic model that correlates with other key operation parameters defined in the context lock protocol We studied and demonstrated the effect of each operation parameters on

PAGE 160

160 APPENDIX A DDL DATA MODELS This appendix presents graph representations for data models of DDL devices. The tree graphs provide a hierarchical view of DDL data mo dels of sensors, actuator s and complex devices as shown in Figure A 1 The graph is also a map for all the elements of the DDL language. In the map, each tree node represents an element whose contents are represented by its sub tree. In addition, we use various symbols to represent the number of occurrences of each element as shown in Table A 1 Figure A 2 and Figure A 3 in this appendix presents the hierarchical structure of data models for sensors and data models respectively. Table A 1. Symbols notat ions for element occurrences. Notation Meaning ? Zero or one Zero or more + One or more {} Choose one

PAGE 161

161 DDL := {Sensor, Actuator, Device} Figure A 1. The data model of the DDL root element. Sensor := (Description, Interface) Descr iption := (Name, Verbose_Description ?, Physical, Version ?, Device_Type, Vendor ?, UniqueId, Location) Physical := (Dimensions ?, Operating_Environment ?) Dimensions := (Length, Width, Height) Operating_Environment := (Temperature, Humidity) Interfac e := (Signal +, Reading +) Signal := (Operation, Type, Measurement, Unit, Number, Range) Range := (Min, Max) Reading := (Type, Computation, Measurement, Unit) Computation := (Type, Expression, Range) Figure A 2 DDL Data Model for Sensor Device := (Desc ription, Interface) Description := (Name, Verbose_Description ?, Physical, Version ?, Device_Type, Vendor ?, UniqueId, Location) Physical := (Dimensions ?, Operating_Environment ?) Dimensions := (Length, Width, Height) Operating_Environment := (Temper ature, Humidity) Interface := (Signal +, Reading +) Signal := (Operation, Type, Method_Name, Parameter +, Frequency Permissible_Status ) Parameter := (Parameter_Name, Parameter_Characterization) Range := (Min, Max) Reading := (Type, Computation, Measuremen t, Unit) Computation := (Type, Expression, Range) Figure A 3 DDL Data Model for Device.

PAGE 162

162 APPENDIX B XML SCHEMA FOR DDL < xsd:schema xmlns:xsd =" http://www.w3.org/2001/XMLSchema "> < xsd:complexType name =" DDL "> < xsd:sequence > < xsd:element name =" Sensor type =" Sensor minOccurs =" 0 maxOccurs =" 1 /> < xsd:element name =" Actuator type =" Actuator minOccurs =" 0 maxOccurs =" 1 /> < xsd:element name =" Device type =" Device minOccurs =" 0 maxOccurs =" 1 /> < xsd:attribute name =" version ty pe =" xsd:string /> < xsd:complexType name =" Sensor "> < xsd:sequence > < xsd:element name =" Description type =" Description minOccurs =" 1 maxOccurs =" 1 /> < xsd:element name =" Interface type =" Interface minOccurs =" 1 maxOccurs =" 1 /> < / xsd:sequence > < xsd:complexType name =" Actuator "> < xsd:sequence > < -Actuator Type is to be defined -> < xsd:complexType name =" Device "> < xsd:sequence > < xsd:element name =" Description type =" Descri ption minOccurs =" 1 maxOccurs =" 1 /> < xsd:element name =" Interface type =" Interface minOccurs =" 1 maxOccurs =" 1 /> < xsd:complexType name =" Description "> < xsd:sequence > < xsd:element name =" Name minOccurs =" 1 maxOccu rs =" 1 "> < xsd:simpleType > < xsd:restriction base =" xsd:string />

PAGE 163

163 < xsd:element name =" Device_Type minOccurs =" 1 maxOccurs =" 1 "> < xsd:simpleType > < xsd:restriction base =" xsd:string "> < xsd:enumeration value =" Physical /> < xsd:enumeration value =" Virtual /> < xsd:element name =" Verbose_Description minOccurs =" 0 maxOccurs =" 1 "> < xsd:simpleType > < xsd:restriction base =" xsd:string /> < xsd:element name =" Vendor minOccurs =" 0 maxOccurs =" 1 "> < xsd:simpleType > < xsd:restriction base =" xsd:string /> < xsd:element name =" Version minOccurs =" 0 maxOccurs =" 1 "> < xsd:simpleType > < xsd:restriction base =" xsd:string /> < xsd:element name =" Physical type =" Physical minOccurs =" 1 maxOccurs =" 1 /> < xsd:element name =" UniqueId type =" UniqueId minOccurs =" 0 maxOccurs =" 1 /> < xsd:element name =" Location type =" Location minOccurs =" 0 maxOccurs =" 1 /> < xsd:complexType name =" Physical "> < xsd:sequence > < xsd:element name =" Dimensions type =" Dimensions minOccurs =" 0 maxOccurs =" 1 /> < xsd:element name =" Operating_environment type =" Op erating_environment minOccurs =" 0 maxOccurs =" 1 />

PAGE 164

164 < xsd:complexType name =" Dimensions "> < xsd:sequence > < xsd:element name =" Length minOccurs =" 1 maxOccurs =" 1 "> < xsd:simpleType > < xsd:restriction base =" xsd:float /> < xsd:element name =" Width minOccurs =" 1 maxOccurs =" 1 "> < xsd:simpleType > < xsd:restriction base =" xsd:float /> < xsd:element name =" Height minOccurs =" 1 maxOccurs =" 1 "> < xsd:simpleType > < xsd:restriction base =" xsd:float /> < xsd:complexType name =" Operating_environment "> < xsd:sequence > < xsd:element name =" Temperature type =" Temperature minOccurs =" 0 maxOccurs = 1 /> < xsd:element name =" Humidity type =" Humidity minOccurs =" 0 maxOccurs =" 1 /> < xsd:complexType name =" Temperature "> < xsd:sequence > < xsd:element name =" Range type =" Range minOccurs =" 1 maxOccurs =" 1 /> < xsd:complexType name =" Humidity "> < xsd:sequence > < xsd:element name =" Range type =" Range minOccurs =" 1 maxOccurs =" 1 />

PAGE 165

165 < xsd:complexType name =" Range "> < xsd:sequence > < xsd:element name = Max minOccurs =" 1 maxOccurs =" 1 "> < xsd:simpleType > < xsd:restriction base =" xsd:float /> < xsd:element name =" Min minOccurs =" 1 maxOccurs =" 1 "> < xsd:simpleType > < xsd:restriction base =" xsd:float /> < xsd:complexType name =" UniqueId "> < xsd:sequence > < -Encoding scheme to be decided -> < xsd:attribute name =" type type =" xsd:string /> < xsd:complexType n ame =" Location "> < xsd:sequence > < -Encoding scheme to be decided -> < xsd:attribute name =" type type =" xsd:string /> < xsd:complexType name =" Interface "> < xsd:sequence > < xsd:element name =" Signal type =" Signal minOc curs =" 0 maxOccurs =" unbounded /> < xsd:element name =" Reading type =" Reading minOccurs =" 0 maxOccurs =" 1 />

PAGE 166

166 < xsd:complexType name =" Signal "> < xsd:sequence > < xsd:element name =" Operation minOccurs =" 1 maxOccurs =" 1 "> < xsd:simpleType > < xsd:restriction base =" xsd:string "> < xsd:enumeration value =" Input /> < xsd:enumeration value =" Output /> < xsd:element name =" Type minOccurs =" 1 maxOccurs =" 1 "> < xsd:simpleType > < xsd:restriction base =" xsd:string "> < xsd:enumeration value =" Analog /> < xsd:enumeration value =" Digital /> < xsd:enumeration value =" Protocol /> < xsd:enumeration value =" Logical /> < xsd: element name =" Measurement minOccurs =" 0 maxOccurs =" 1 "> < xsd:simpleType > < xsd:restriction base =" xsd:string /> < xsd:element name =" Unit minOccurs =" 0 maxOccurs =" 1 "> < xsd:simpleType > < xsd:restriction base =" xsd:strin g /> < xsd:element name =" Number minOccurs =" 0 maxOccurs =" 1 "> < xsd:simpleType > < xsd:restriction base =" xsd:string "> < xsd:enumeration value =" Multiple /> < xsd:enumeration value =" Single />

PAGE 167

167 < xsd:element name =" Range type =" Range minOccurs =" 0 maxOccurs =" 1 /> < xsd:element name =" Method_name minOccurs =" 0 maxOccurs =" 1 "> < xsd:simpleType > < xsd:restriction base =" xsd:string "> < xsd:element name =" Parameter type =" Parameter minOccurs =" 0 maxOccurs =" unbounded /> < xsd:element name =" Frequency minOccurs =" 0 maxOccurs =" 1 "> < xsd:simpleType > < xsd:restriction base =" xsd:integer "> < xsd:element name =" Allowed_Status minOccurs =" 0 maxOccurs =" 1 "> < xsd:simpleType > < xsd:restriction base =" xsd:string "> < xsd:enumeration value =" INIT /> < xsd:enumeration value =" BINDED /> < xsd:enu meration value =" ALIGNED /> < xsd:enumeration value =" EXEC /> < xsd:enumeration value =" TERMINATE /> < xsd:enumeration value =" EMERGENCY /> < xsd:enumeration value =" ERROR /> < xsd:enumeration value =" ALL /> < xsd:attribute name =" id type =" xsd:string /> < xsd:complexType name =" Parameter "> < xsd:sequence > < xsd:element name =" Parameter_name minOccurs =" 1 maxOccurs =" 1 "> < xsd:simpleType > < xsd:restriction base =" xsd:str ing ">

PAGE 168

168 < xsd:element name =" Parameter_characterization type =" xsd:float minOccurs =" 0 maxOccurs =" unbounded "/> < xsd:attribute name =" id type =" xsd:string use =" required /> < xsd: attribute name =" enumeration type =" xsd:boolean use =" required /> < xsd:attribute name =" discrete type =" xsd:boolean use =" required /> < xsd:complexType name =" Reading "> < xsd:sequence > < xsd:element name =" Type minOccurs =" 1 maxOccurs = 1 "> < xsd:simpleType > < xsd:restriction base =" xsd:string "> < xsd:enumeration value =" Basic /> < xsd:enumeration value =" Derived /> < xsd:enumeration value =" Physical /> < xsd:element name =" Measu rement minOccurs =" 1 maxOccurs =" 1 "> < xsd:simpleType > < xsd:restriction base =" xsd:string /> < xsd:element name =" Unit minOccurs =" 0 maxOccurs =" 1 "> < xsd:simpleType > < xsd:restriction base =" xsd:string /> < xsd:element name =" Computation type =" Computation minOccurs =" 0 maxOccurs =" 1 /> < xsd:element name =" Range type =" Range minOccurs =" 0 maxOccurs =" 1 /> < xsd:attribute name =" id type =" xsd:string />

PAGE 169

169 < xsd:complexType name =" Computation "> < xsd:sequence > < xsd:element name =" Type minOccurs =" 1 maxOccurs =" 1 "> < xsd:simpleType > < xsd:restriction base =" xsd:string "> < xsd:enumeration value =" Aggregate /> < xsd:enumeration value =" Formula /> < xsd:enumeration value =" Map /> < xsd:element name =" Expression minOccurs =" 0 maxOccurs =" 1 "> < xsd:simpleType > < xsd:restriction base =" xsd:string />

PAGE 170

170 APPENDIX C SAMPLE DDL DOCUMENT FOR TMP36 ANALOG TEM PERATURE SENSOR < DDL version =" 1.21 "> < Sensor > < Description > < Name > Temperature Sensor < Device_Type > Physical < Verbose_ Description > TMP36 Analog Temperature Sensor < Vendor > University of Florida < Version > 1.0 < Physical > < Dimensions > < L ength > 24 < W idth > 34 < H eight > 24 < Operating _e nvironment > < Temper ature > < Range > < M in >< / M in > < Max >< / Max >

PAGE 171

171 < Humidity > < Range > < M in >< / M in > < Max >< / Max > < / Operating _e nvironment > < Interface > < Sign > < Operation > Input < Type > Analog Measurement attribute of another physical/virtual sensor -> < Measurement > ADC < Unit > null < Number > Single < Range > < Min > 0 < Max > 1023

PAGE 172

172 < Reading > < Type > Physical < Measurement > Temperatur e < Unit > Centigrade < Computation > < Type > Formula < Expression > reading = (((s1/1023)*3.3) 0.5)*(1000/ 10) < Range > < Min > < Max >

PAGE 173

173 APPENDIX D DATA STRUCTURE DESIG N FOR PERVASIVE TRAN SACTION PROCESSOR class TransactionInst ance{ int transactionID; Vector operations ; enum submissionStatus ; enum processingStatus ; Time arrival ; Time start ; Time finish ; } class TransactionPoolManager{ int submitTx(); //returns ID of the transaction boolean update Tx(int txID); boolean closeTx(int txID); } class TransactionScheduler{ enum schedulingS trategy ; TransactionInstance getNextTx(); void setStragtegy(); } class TransactionPool{ LinkedList tra nsactions ; TransactionPoolManager pmngr ; TransactionScheduler ts ; } class Operation{ TransactionInstance t ; Time start ; Time finish ; int operationStatus ; ContextEntity operand ; boolean isCompatible (Opeartion op ); boolean isCompatible (ContextLock cl ); } class Sensing extends Operation{ double delta ; boolean onExecute(); } class Actuation extends Operation{

PAGE 174

174 double sigma; boolean onExecute(); } class TransactionProcessor { static TransactionPool tP ool ; static ContextLockManager lockManager ; static ContextMap cMap ; TransactionInstance currentTransaction ; void processingCycle(); void lockSchedule(); void processOperation(); void onAbort(); boolean onCommit(); } class ContextL ockManager { static ContextMap cMap ; static ContextMonitor monitor ; boolean onReqeust(Operation op ); boolean onUpgrade(Operation op ); boolean onDegrade(ContextLock cl ) boolean onRelease(ContextLock cl ); boolean onRevoke(Cont extLock cl ); void onViolation(Constraint c Operation op ); } class ContextMap{ Collection contextEntities ; } class ContextEntity{ HashMap cache; Collection lockTable ; Collection getRead ers(); Collection getWriters(); Reading updateCurrentVal(); } abstract class ContextLock{ ContextEntity protectedEntity; int l ockStatus ; int getLockStatus(); abstract boolean isCompatible(ContextLock lock ); }

PAGE 175

175 class ReadLock extends Cont extLock{ Sensing sensing ; boolean isCompatible(ContextLock lock ); } class WriteLock extends ContextLock{ Actuation actuation ; boolean isCompatible(ContextLock lock ); }

PAGE 176

176 LIST OF REFERENCES 1. Chen, C., Helal, A. Device Integration in SODA using the D evice Integration Language. In Proc. SAINT 2009 IEEE, 100 106, 2009. Best Paper Award. 2. Chen, C., Xu, Y., Li, K., Helal, A. Reactive Programming Optimizations in Pervasive Computing, In Proc. SAINT 2010 IEEE, 96 104 2010. Best Paper Award. 3. Yang, H., He lal. A. Safety Enhancing Mechanisms for Pervasive Computing Systems in Intelligent Environment. In: Middleware Support for Pervasive Computing Workshop, held in conjunction with IEEE PerCom 2008, Hong Kong, 2008. 4. Weiser, M, Brown, J.S. The Coming Age of C alm Technology. 1996. 5. Kay, A. Computers, Networks, and Educations. Sci. Am. (Sept. 1991), 138 148. 6. Weiser, M. Some Computer Science Issues in Ubiquitous Computing. ACM SIGMOBILE Mobile Computing and Communications Review Volume 3, Issue 3, July 1999. 7. DSSE Group in University of South Hampton, Safety in Pervasive Computing, Advanced Specialization and Analysis for Pervasive Computing project deliverable report D13. 2003. 8. Occupational Safety and Health Administration, U.S., http://www.osha.gov/ 9. The Housing Health and Safety Rating System, U.K., http://www.communities.gov.uk/hhsrs 10. Chen, C. Helal, S. Toward a Programming Model for Safer Pervasive Spaces. 2010 Symposi a and Workshops on Ubiquitous, Autonomic and Trusted Computing 57. 11. Chen, C., Helal, S., de Deugd, S. and Smith, A. Roles and System Architecture in the Design, Creation and Management of Smart Spaces. in proceedings of Workshop on Programming Methods for Mobile and Pervasive Systems in conjunction with Pervasive 2010, Helsinki, Finland. 12. Ramamritham, K and Chrysanthis, P. K. Advances in Concurrency Control And Transaction Processing. IEEE Computer Society 1997. 13. Henricksen, K. Indulska, J. and Rakotonirainy, A. Modeling Context Information in Pervasive Computing Systems. Pervasive 2002 LNCS 2414, pp. 167 180, 2002.

PAGE 177

177 14. Gray, P. D., Salber, D. Modeling and Using Sensed Context Information in the Design of Interactive Applications Proceedings of the 8th IFIP Working Conference on Engineering for Human Computer Interaction (EHCI'01), Toronto, Canada, May 2001. 15. Helal, A., Mann, W., Elzabadani, H., King, J., Kaddourah Y. and Jansen, E. Gator Tech Smart House: A Programmable Pervasi ve Space. IEEE Computer magazine, March 2005, pp 64 74. 16. Analog Devices, Inc. http:// www.analog.com/ 17. Life Source, A&D Medical, Inc. http://www.andonline.com/ 18. Atlas Middlewa re, Pervasa, Inc., http:// www.pervasa.com / 19. Edge Frontier, Augusta Systems, Inc. http://www.augustasystem.com/ 20. Helal A., Chen, C. The Gator Tech Smart House: Enabling Te chno logies and Lessons Learned. Proceedings of the 3rd International Convention on Rehabilitation Engineering & Assistive Technology (i April, 2009. Singapore 21. Yang, H. S afety Oriented Programming Models for Pervasive Computing Environments Ph.D. dissertation 2008. 22. Weiser, M. The Computer for the 21st Century. Scientific American September, 1991. 23. Satyanarayanan, M. Pervasive Computing: Vision and Challenges. IEEE Personal Communications Vol 8, Issue 4. Aug 2001. pp. 10 17. 24. Chen, C., Bos e, R., Helal, A. Atlas: An Open Model for Automatic Integration and Teleprogramming of Smart Objects, Proceedings of 3rd International Workshop Orlando Oct 2009. 25. Chen, C. Helal. A. Siftin g Through the Jungle of Sensor Standards, IEEE Pervasive Computing Volume: 7, Issue: 4. Oct Dec 2008. 26. Tan, W., et al. Mine Fire Detection System Based on Wireless Sensor Network. Proc. ICIA 07 IEEE, 2007, 148 151. 27. Kortuem, G., et al. Sensor Networks or Smart Artifacts? An Exploration of Organizational Issues of an Industrial Health and Safety Monitoring System. Springer, 2007, 465 482.

PAGE 178

178 28. Zhou, J., et al. Application of Modern Sensor and Info Technology in Long Term Safety Monitoring of Long Span Rigid Frame Bridge. Telecommunications IEEE, 2006. 37 40. 29. Jiang, C., Peng, J. Research, manufacture and application of GPS based surveying robot automatic monitoring system for dam safety Proc. ICIS 2009 IEEE, 2009. 151 155. 30. Liu, C., Teng, P. The Safety Design of the Laboratory Monitoring System. Proc. ICIS 2010 IEEE, 2010. 373 376. 31. da Silva Sa, J. et al. Monitoring of Temperature Using Smart Sensors Based on CAN Architecture. Proc. C ONIELECOMP 2005 IEEE, 2005, 218 222. 32. Ramamritham, K and Chrysanthis, P. K. Advances in Concurrency Control And Transaction Processing. IEEE Computer Society 1997. 33. Helal, S. Programming Pervasive Spaces. IEEE Pervasive Computing IEEE 2005. 84 87. 34. Ma, J., et al. Ubisafe Computing: Vision and Challenges (I). Proc. Autonomic and Trusted Computing 2006. Springer 2006. 386 397. 35. Risk informed, Multi Hazard Resilience of Built Environment via Cyber Worlds Sharing Proc. Cyberworlds 2010 IEEE 2010. 445 450. 36. Yao, T. et al. Multi Feature Fusion Based Outdoor Water Hazards Detection. Proc. ICMA 2007 IEEE 2007. 652 656. 37. Yang, H., Chen, C., Bessam, A. Helal A A Framework for Evaluating Pervasive Sy stems, International Journal of Pervasive Computing and Communications (IJPCC), Vol 6 issue 4 (2010), Emerald Press. Nov, 2010. 38. Yang, H. et al. A Context Driven Programm ing Model for Pervasive Spaces. I n proceedings of 5th International Conference on Smar t Homes and Health Telematics (ICOST ) Springer 2007. 31 43 39. Gu, T., Pung, H. K. and Yao J. K. Towar ds a Flexible Service Discovery. Elsevier Journal of Network and Computer Applications (JNCA) Vol. 28, Issue 3, Elsevier 2005. 233 248 40. Fitterer, R. and de Witte, B. Enabling Pervasive Healthcare by Means of Event Driven Service Oriented Architectures The Case of Bed Management in Mid Sized to Large Sized Hospitals. In proceedings of 3rd International ICST Conference on Pervasive Computing Technologi es for Healthcare London.

PAGE 179

179 41. Boukerche, A., Pazzi, R. W. N. Araujo, R. B. A fast and reliable protocol for wireless sensor networks in critical con ditions monitoring applications. In proceedings of 7th ACM international symposium on modeling, analysis and s imulation of wireless and mobile systems 2004 157 164 42. Chen, C., Helal, A. A Device centric Approach to Enhance Safety of the Internet of Things, International Workshop on Networking and Object Memories for the Internet of Things (NOMe IoT 2011). In conj unction with Ubicomp 2011 43. Cho, E. S., Helal, S. A Situation based Exception Detection Mechanism for Safety in Pervasive Systems. Proc. SAINT 2011 IEEE 2011 44. Ulrich, R., Miller, J. Information Processing Models Generating Lognormally Distributed Reactio n Times, Journal of Mathematical Psychology Vol. 37, Issue 4 December 1993, 513 525 45. Sanzo, P.D., Palmieri, R., Romano P. Analytical Modeling of Lock based Concurrency Control with Arbitrary Transaction Data Access Patterns. 0 Jan, 2010. 46. Leveson N. Safeware: System Safety and Computers Addison Wesley. 1995. 47. Chen Z., Motet G System Safety Requirements As Control Structures. Seattle, WA, USA. July 2009. 324 331. 48. Martins, F., Lopes, L., Barros J Towards the Safe Programming of Wireless Sensor Networks. Journal of EPTCS 17 2010. 49 62. 49. Lanzisero T Taking HBSE to the next level. In Proceedings of 2010 Symposium on Product Compliance Engineering (ISPCE 2010) Oct 2010. 1 6. 50. Kelly T., Weaver R The Goal Structuring Notation A Safety Argument Notation. In Proc. of Dependable Systems and Networks. 2004 Workshop on Assurance Cases 2004. 51. Holloway C. M Safety Case Notations: Alterna tives For The Non Graphically Inclined ? In Proceedings of 2008 3rd IET International Conference on System Safety. Oct 2008. 1 6. 52. McDermid, J. A. Pumfrey D. J. Safety Analysis of Hardware / Software Interactions in Complex Systems. Proceedings of the 16t h International System Safety Conference Seattle, WA, USA 1998. 232 241. 53. Railtrack. Engineering Safety Management The Yellow Book. Rail Safety and Standards Board 2007.

PAGE 180

180 54. Baskar S Enforcing safety in pervasive computing environments. Ph.D. Dissertation Perdue University. 2003. 55. de Champs T et al. Pervasive safety application with model checking in smart houses: The INOVUS intelligent oven. In Proceedings of 2011 IEEE International Conference on Pervasive Computing and Communications Workshops (PERCOM Workshops) 2011. Seattle, WA. 630 635. 56. The Engineers' Council for Professional Development. Science Volume 94, Issue 2446, 1941. pp. 456 57. U.S. Bureau of Transportation Statistics (2010) National Transportation Statistics. Table 2 1: Transportation Fatalities by Mode (Report). Retrieved 2010 02 14. 58. Haxthausen, A. E., Peleska J Formal development and verification of a distributed railway control system IEEE transacti on on Software Engineering Volume: 26 Issue:8 2000. 687 701. 59. Kletz T. Human problems with computer control. Plant/Operations Progress vol. 1, no. 4, 1982. 60. Chetan, S., Rang anathan, A., Campbell R Towards fault tolerance pervasive computing. Technology and Society Magazine IEEE, 24(1):38 -44, Spring 2005. 61. Xia, J., Chang, C., Kim, T., Y ang, H., Bose R., Helal, A. Fault resilient Ubiquitous Service Composition Proceedings of 3rd IET International Conference on Intelligent Environments (IE'07), Ulm University, Germany, September 24 25, 2007. 62. Khalid A., et al. Survey of Frameworks, Architectures and Techniques in Autonomic Computing, Fifth International Conference on Auton omic and Autonomous Systems 2009. 63. P. Hu, J. Indulska, R. Robinson, An Autonomic Context Management System for Pervasive Computing, Proceedings of the 2008 Sixth Annual IEEE International Conference on Pervasive Computing and Communications 2008. 213 223 64. Kulkarni, D., Tripathi, A.: A Framework for Programming Robust Context Aware Application s IEEE Transactions on Software Engineering vol. 36, no. 2, IEEE Computer Society Press, 2010 65. Damasceno, K., Cacho, N., Garcia, A., Romanovsky, A., Lucena, C. Con text Aware Exception Handling in Mobile Agent Systems: The MoCA Case Software engineering for large scale multi agent systems ACM New York 37 44 2006.

PAGE 181

181 66. Augusto, J. C., Mccullagh, P. J., Carlos, J., & Paul, A. Safety Considerations in the Development of Intelligent Environments. Ambient Intelligence Software and Applications 92, 197 204. 2001. 67. Gabriel, P., Bovenschulte, M., Hartmann, E., Gro, W., Strese, H., Bayarou, K. M., Haisch, M., et al. Pervasive Computing: Trends and Impacts SecuMedia. Ret rieved from http://www.bsi.de/literat/studien/percenta/Percenta_elay.pdf 2006. 68. Ma J., et al. Ubisafe Computing: Visiosn and Challenges (I). In Proceedings of Autonomic and Trus ted Computing (ATC). 386 397. 2006. 69. Gupta, S., Chen, Ke Yu., Reynolds, M., Patel, S.N. LightWave: Using Compact Fluorescent Lights as Sensors. UbiComp 2011 Beijing, China, September 17 21, 2011. 70. Cohn, G., Gupta, S., Froehlich, J., Larson, E., and Patel S. GasSense: Appliance Level, Single Point Sensing of Gas Activity in the Home. Proceedings of Pervasive 2010 Helsinki, Finland, May 17 20, 2010. 71. Patel, S.N., Reynolds, M.S., Abowd, G.D. Detecting Human Movement by Differential Air Pressure Sensing in HVAC System Ductwork: An Exploration in Infrastructure Mediated Sensing. In the Proceedings of Pervasive 2008 Sydney, Australia. 2008. pp 1 18. 72. Larson, E.C., Goel, M., Boriello, G., Heltshe, S., R osenfeld, M., Patel, S.N SpiroSmart: Using a Microphone to Measure Lung Function on a Mobile Phone. Proceedings of the 14th International Conference on Ubiquitous Computing (UbiComp 2012) Pittsburgh, USA, Sep 5 8, 2012.

PAGE 182

182 BIOGRAPHICAL SKETCH Chao Chen received a Bachelor of Science degree in Compute r Science from Nanjing University (Nanjing, China) in 2006. In the same year, he was admitted to the Ph.D. program at the University of Florida. His research focuses on programming models to support automatic integration and safety in pervasive systems. He received his Ph.D. from the University of Florida in the fall of 2012.