Safety-Oriented Programming Models for Pervasive Computing Environment

Material Information

Safety-Oriented Programming Models for Pervasive Computing Environment
Yang, Hen
Place of Publication:
[Gainesville, Fla.]
University of Florida
Publication Date:
Physical Description:
1 online resource (161 p.)

Thesis/Dissertation Information

Doctorate ( Ph.D.)
Degree Grantor:
University of Florida
Degree Disciplines:
Computer Engineering
Computer and Information Science and Engineering
Committee Chair:
Helal, Abdelsalam A.
Committee Members:
Newman, Richard E.
Chen, Shigang
Yavuz, Tuba
Najafi, Fazil T.
Graduation Date:


Subjects / Keywords:
Application programming interfaces ( jstor )
Computer programming ( jstor )
Computer technology ( jstor )
Mechanical systems ( jstor )
Mechanism design ( jstor )
Programming models ( jstor )
Sensors ( jstor )
Software ( jstor )
Systems design ( jstor )
Ubiquitous computing ( jstor )
Computer and Information Science and Engineering -- Dissertations, Academic -- UF
authoring, pervasive, programming, safety, soa, system, tool, ubiquitous
Electronic Thesis or Dissertation
born-digital ( sobekcm )
Computer Engineering thesis, Ph.D.


Pervasive computing systems provide personalized and intimate services to improve the quality of life by offering seamlessly integrated computation and communication at users' disposal. Since they have the capability to interact with the physical world and are designed to assist or manage aspects of users' daily lives, the requirement for certain level of safety guarantee is high and imminent. Enhancing safety proves to be challenging because of the inherent dynamicity, complexity, heterogeneity and uncertainty typical in the pervasive computing environment. These attributes make applying a single external overarching mechanism to enforce safety measures infeasible. The better solution is to incorporate safety-aware software practice and enforcement mechanisms at the design and implementation phases, and a bottom-up approach to ensure the safety of each component as well as the interactions between them. It allows elimination of some safety risks before they are deployed, and monitors and handles others at runtime. A system analysis is performed to identify the four fundamental elements of any pervasive computing system, and to establish a formal model for each of these elements. A risk analysis follows, which outlines the potential safety hazards resulting from the system design and implementation flaws, and uncontrollable factors such as natural disasters and human errors. Based on the findings from these analyses, a safety mechanism is designed and implemented to reduce, detect and handle various risks. To seek a more natural and effective solution, we explore an alternative programming model focusing on context at its core. It allows for powerful yet easy detections of conflicts, dangerous situations and illogical goals or actions. It is entirely user-centric, and allows programmers and users to grasp the complete status of the space. Furthermore, a programming procedure with linear complexity is established and the automatic optimal action plan evaluation process is devised. Safety concern is one of the major hurdles preventing pervasive systems from being widely adopted, we believe the proposed enhancements in safety and reliability can go a long way in earning the trust of general public on this emerging technology. ( en )
General Note:
In the series University of Florida Digital Collections.
General Note:
Includes vita.
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.
Thesis (Ph.D.)--University of Florida, 2008.
Adviser: Helal, Abdelsalam A.
Electronic Access:
Statement of Responsibility:
by Hen Yang.

Record Information

Source Institution:
University of Florida
Holding Location:
University of Florida
Rights Management:
Copyright Yang, Hen. Permission granted to the University of Florida to digitize, archive and distribute this item for non-profit research and educational purposes. Any reuse of this item in excess of fair use or other copyright exemptions requires permission of the copyright holder.
Embargo Date:
LD1780 2008 ( lcc )


This item has the following downloads:

Full Text




2 2008 Hen I Yang


3 TABLE OF CONTENTS page TABLE OF CONTENTS ................................ ................................ ................................ ................. 3 LIST OF TABLES ................................ ................................ ................................ ........................... 7 LIST OF FIGURES ................................ ................................ ................................ ......................... 8 LIST OF TERMS/SYMBOLS/ABBREVIATIONS ................................ ................................ ....... 9 ABSTRACT ................................ ................................ ................................ ................................ ... 10 CHAPTER 1 INTRODUCTION ................................ ................................ ................................ .................. 12 1.1 Pervasive Computing ................................ ................................ ................................ ... 12 1.2 Safety Issues in Pervasive Computing System s ................................ ........................... 13 1.3 Motivation ................................ ................................ ................................ .................... 14 1.4 Scope ................................ ................................ ................................ ............................ 17 2 PROBLEM STATEMENT ................................ ................................ ................................ ..... 18 2.1 Defining Safety ................................ ................................ ................................ ............ 18 2.2 Objectives ................................ ................................ ................................ .................... 19 2.3 Challenges ................................ ................................ ................................ .................... 20 2.4 Strategy ................................ ................................ ................................ ........................ 22 2.5 Approach ................................ ................................ ................................ ...................... 23 3 RELATED WORK ................................ ................................ ................................ ................. 25 3.1 Software and Computing System Safety ................................ ................................ ..... 25 3.2 Programming Models and Tools ................................ ................................ .................. 27 3.3 Middleware Architecture for Pervasive Co mputing ................................ .................... 29 3.4 Context Aware Computing ................................ ................................ .......................... 32 3.5 Atlas Architecture ................................ ................................ ................................ ........ 34 4 ANA LYSIS OF PERVAISVE COMPUTING SYSTEMS ................................ .................... 36 4.1 Survey of Pervasive Computing Systems ................................ ................................ .... 36 4.1.1 Location Aware System: Bat ................................ ................................ ............ 36 4.1.2 Smart Homes: Aware Home, Gator Tech Smart House, iDorm ...................... 37 4.1.3 Interactive Museum: Exploratorium, Costa Aquarium Hypermedia Guide ..... 38 4.1.4 Smart Laboratory: Labscape, e Science ................................ ........................... 39 4.1.5 Context aware Health Care: iHospital ................................ .............................. 39 4.1.6 Telematics: Data Protection Framework, Project 54, IT Cruiser ..................... 40


4 4.1.8 Outdoors Deployment: Great Duck Island, GUIDE ................................ ......... 41 4.1.9 Comparisons and Discussions ................................ ................................ .......... 42 4.2 Commonality among Existing Pervasive Computing Systems ................................ ... 43 4.3 Four Fundamental Elements ................................ ................................ ........................ 45 5 FORMAL MODEL OF PERVASIVE COMPUTING SYSTEM ................................ .......... 52 5.1 Formal Model of the Fundamental Elements ................................ ............................... 52 5.1.1 Observing the World with Sensors ................................ ................................ ... 52 Defining and Interpreting Context ................................ ............................ 54 Current State of the World ................................ ................................ ........ 56 5.1.2 Influencing the World with Actuators ................................ .............................. 57 5.1.3 Enriching the World with Services ................................ ................................ ... 60 5.1.4 Inhabiting the World as a User ................................ ................................ ......... 60 5.1.5 Shaping the World as a Programmable Pervasive Space ................................ 63 5.2 Representation and Manifestation of the Fundamental Elements ................................ 64 5.2.1 Device ................................ ................................ ................................ ............... 65 5.2.3 Service ................................ ................................ ................................ .............. 65 5.2.3 User ................................ ................................ ................................ ................... 66 5.2.4 Space ................................ ................................ ................................ ................. 67 6 RISK ANALYSIS ................................ ................................ ................................ .................. 69 6.1 Scenarios ................................ ................................ ................................ ...................... 69 6.2 Risk Analysis ................................ ................................ ................................ ............... 71 6.2.1 Risks Associated with a Single Hardware or Software Component ................ 71 Component not fail safe ( h ardware and s oftware) ................................ .... 71 Overextended resource ................................ ................................ .............. 72 6.2 .2 Risks Associated with Component Interaction s and the Co existing of Components ................................ ................................ ................................ ................. 73 Shared resource related safety risks ................................ .......................... 73 6 .2.2.2 Race condition ................................ ................................ ........................... 74 Conflicting goals ................................ ................................ ....................... 74 Lack of scalability and inability to add components ................................ 75 Inability to adapt or substitute services properly ................................ ...... 76 Conflicting side effects ................................ ................................ .............. 76 6.2.3 Risks Associated with Space ................................ ................................ ............ 77 Violation of space specific attributes ................................ ........................ 77 Vague definition and inadequate monitoring of impermissible contexts ................................ ................................ ................................ ................. 77 Events caused by uncontrollable factors ................................ ................... 78 6.2.4 Risks Associated with User ................................ ................................ .............. 79 Violation of user centric computing ................................ ......................... 79 Irrationality of users ................................ ................................ .................. 80 Unintentional disruptive user actions ................................ ........................ 80 6.2.5 Misunderstanding about the System ................................ ................................ 81 6.3 Observations and Characteristics of Safety Risks in Pervasive Computing ................ 81


5 7 DESIGN OF SAFETY MECHANISMS ................................ ................................ ................ 84 7.1 Existing Physical, System and Network Safety Mechanisms Ap plicable to Pervasive Computing ................................ ................................ ................................ .......... 84 7.2 Safety Mechanisms Tailored Specifically for Pervasive Computing Systems ............ 85 7.2.1 Device ................................ ................................ ................................ ............... 86 7.2.2 Service ................................ ................................ ................................ .............. 87 7.2.3 User ................................ ................................ ................................ ................... 89 7.2.4 Space ................................ ................................ ................................ ................. 90 7.3 Design Considerations ................................ ................................ ................................ 91 7.3.1 Program Time versus Runtime Safety Measures ................................ ............. 91 7.3.2 Tradeoff between Safety and Power of Expressions ................................ ........ 92 8 IMPLEMENTATION OF SAFETY MECHANISMS ................................ ........................... 94 8.1 Static S afety M echanisms ................................ ................................ ............................ 94 8.1.1 Prioritized Safety API ................................ ................................ ...................... 95 8.1.2 State Machine and Service Safety Interface ................................ ..................... 95 8.1.3 Mandato ry Power Down Sequence ................................ ................................ .. 96 8.1.4 Preemptive Methods with Priority ................................ ................................ .... 96 8.2 Dynamic Safety Mechanisms ................................ ................................ ...................... 96 8.2.1 Device Safety Checker ................................ ................................ ..................... 97 8.2.2 Context Manager and Emergency Detector ................................ ...................... 97 8.2.3 Service Registry and Emergency Handler Vector (EHV) ................................ 97 8.2.4 User Manager ................................ ................................ ................................ ... 98 8.3 Safety oriented Service based Programming Model ................................ ................... 98 8.3.1 Programming Services ................................ ................................ .................... 101 8.3.2 Programming User Representations ................................ ............................... 102 8.3.3 Programming Spac e Specifications ................................ ................................ 103 8.4 Safety Protection at Runtime ................................ ................................ ..................... 104 8.4.1 Initialization ................................ ................................ ................................ .... 104 8.4.2 Execution ................................ ................................ ................................ ........ 106 8.5 The Effectiveness of Proposed Safety Mechanisms ................................ ....................... 108 8. 5.1 Scenarios ................................ ................................ ................................ ......... 108 8. 5 2 Discussion ................................ ................................ ................................ ....... 110 8.6 Authoring Tool ................................ ................................ ................................ ........... 111 9 AN ALTERNATIVE: THE CONTEXT DRIVEN PROGRAMMING MODEL ............... 117 9.1 Context Driven Programming Model ................................ ................................ ........ 118 9.1.1 Shortcomings of SOA and SOA like Programming Models .......................... 118 9.1.2 Design of the Context Driven Programming Model ................................ ...... 119 9.2 Modified Formal Model ................................ ................................ ............................. 120 9.3 Programm ing Procedure ................................ ................................ ............................ 121 9.4 Capabilities and Limitations ................................ ................................ ...................... 125 9.4.1 Capabilities ................................ ................................ ................................ ..... 125 Detecting issues related to contexts and goals: ................................ ....... 126


6 Detecting issues related to intentions and actions: ................................ .. 127 9.4.1 .3 Strong adherence to user centric computing: ................................ .......... 127 Better understanding of the system ................................ ......................... 128 9.4.2 Limitations ................................ ................................ ................................ ...... 130 9.5 Scenario ................................ ................................ ................................ ...................... 131 10 CONCLUSION AND FUTURE WORK ................................ ................................ ............. 138 APPENDIX A SEMANTIC DESCRIPTION FILE S ................................ ................................ ................... 141 A.1 Service ................................ ................................ ................................ ........................ 141 A.2 User ................................ ................................ ................................ ............................ 144 A.3 Space ................................ ................................ ................................ .......................... 146 B ................................ ........... 148 B.1 Creation o f a N ew Project ................................ ................................ .......................... 149 B.2 Creation o f S emantic Files ................................ ................................ ......................... 149 B.3 Specification o f Dependent Bundles a nd Projects ................................ ..................... 149 B.4 Filling in the Service Logic into the Generat ed C ode T em plate ............................... 150 B.5 Compilation and verification ................................ ................................ ..................... 150 B.6 Deployment into a runtime system ................................ ................................ ............ 151 LIST OF REFERENCES ................................ ................................ ................................ ............. 153 BIOGRAPHICAL SKETCH ................................ ................................ ................................ ....... 161


7 LIST OF TABLES Table page 4 1 System objectives of representative pervasive computing systems ................................ ... 48 4 2 Sensors, actuators and user roles of pervasive computing systems ................................ ... 49 4 3 Primary characteristics of representative pervasive computing systems ........................... 50 5 1 Attributes included in the device description file ................................ .............................. 68 6 1 Safety risks associated with pervasive computing systems ................................ ............... 83 9 1 Comparison between service oriented and context driven programming models .......... 135


8 LIST OF FIGURES Figure page 2 1 Research agenda ................................ ................................ ................................ ................. 24 3 1 Layered Atlas architecture ................................ ................................ ................................ 35 4 1 Four fundamental elements ................................ ................................ ................................ 51 4 2 Interactions between four fundamental e lements ................................ .............................. 51 7 1 Tradeoff between safety and expressiveness of programming models in pervasive computing ................................ ................................ ................................ .......................... 93 8 1 Updated Atlas Architecture ................................ ................................ .............................. 114 8 2 Priority Safety API ................................ ................................ ................................ ........... 114 8 3 State dia gram for services ................................ ................................ ................................ 115 8 4 Dynamic safety mechanisms in the middleware ................................ .............................. 115 8 5 Software architecture of safe services ................................ ................................ .............. 116 9 1 Domains and contexts of interest ................................ ................................ ..................... 136 9 2 Associating sensors and actuators with domains ................................ ............................. 136 9 3 Intention specifications ................................ ................................ ................................ .... 136 9 4 Construction of high dimension context grid ................................ ................................ .. 137 9 5 Potential action evaluation in the system ................................ ................................ ......... 137 9 6 Three dimensional context grid of the scenario ................................ ............................... 137 B 1 Flowchart for programming services ................................ ................................ ............... 152


9 LIST OF TERMS/SYM BOLS/ABBREVIATIONS API Application programming interface EHV Emergency handler vector GTSH Gator Tech Smart House HCI Human computer interface ISO International Organization for Standardization LL(1) A top down parser for a subset of the context free grammars that parses the in put from left to right, and constructs a Leftmost derivation MTTF Mean time to failure OS Operating system POA Process, Outco me Aff ect Model RFID Radio frequency identification SAE National Institute for Automotive Service Excellence SOA Service oriented architecture Wifi Wireless fidelity XML Extensible markup l anguage


10 Abstract of Dissertation Presented to the Graduate School of t he University of Florida in Partial Fulfillment of the Requirements for the Degree of Doctor of Philosophy SAFETY ORIENTED PROGRAMMING MODEL S FOR PERVASIVE COMPUTING ENVIRONMENT S By Hen I Yang August 2008 Chair: Abdelsalam (Sumi) Hela l Major: Computer Engineering Pervasive computing systems provide personalized and intimate services to improve the quality of life by offering seamlessly integrated computation and communication disposal Since they have the c apab ility to inte ract with the physical world and are designed to assist or manag e e s the requirement for certain level of safety guarantee is high and imminent. Enhanc ing safety proves to be challenging because of the inherent dynamicity, comp lexi ty, heterogeneity and uncertaint y typical in the pervasive computing environment These attributes make applying a single external overarching mechanism to enforce safety measures infeasible. The better solution is to incorporate safety aware software practice and enforcement mechanisms at the design and implementation phases, and a bottom up approach to ensure the safety of each component as well as the interactions between them. It allows elimination of some safety risks before they are deployed, and monitors and handles others at runtime. A system analysis is performed to identify the four fundamental elements of any pervasive computing system, and to establish a formal model for each of these elements. A risk analysis follows, which outlines the pote ntial safety hazards resulting from the system design and


11 implementation flaws, and uncontrollable factors such as natural disasters and human errors. Based on the findings from these analyses, a safety mechanism is designed and implemented to reduce, dete ct and handle various risks. T o seek a more natural and effective solution, we explore an alternative programming model focusing on context at its core. It allows for powerful yet easy detections of conflicts, dangerous situations and illogical goals or ac tions. It is entirely user centric, and allows programmers and users to grasp the complete status of the space. Furthermore, a programming procedure with linear complexity is established and the automatic optimal action plan evaluation process is devised Safety concern is one of the major hurdles preventing pervasive systems from being widely adopted, we believe the proposed enhancement s in safety and reliability can go a long way in earning the trust of general public on this emerging technology.


12 CHA PTER 1 INTRODUCTION 1.1 Pervasive Computing st century is a technology that weaves computations and communications into the fabric of daily life 1 The miniaturizations of computing systems, enhanced wireless commun ication capabilities, high density energy sources and other technical breakthroughs have made invisibility and seamless integration not a futuristic possibility, but a current reality. In the near future, the majority of things connected to the network wou ld not be computers as we know today, but instead consist of smart appliances, sensors, actuators and ordinary objects 2 An imminent paradigm shift in computing is upon us. The pinnacle of pervasive computing is its capability to finally break through and break down the boundary between the physical and digital worlds. The availability of small yet competent sensors allows computing systems to perceive the status and events occurred in the environment. The large quantity of high fidelity data collected and the high level, abstract contexts that can be extracted and interpreted using reasoning engines, allows for computing systems to reason and make decisions. In turn, the systems can manipulate various actuators, such as motors, electronic devices or new gen eration of smart appliances and robots, to interact with the world based on the decisions made. The most impressive aspect of pervasive computing, is perhaps best described by a quote from Mark Weiser, who first proposed the concept of ubiquitous computing also known as pervasive computing, in 1991. 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 1 The idea of bringing computin g systems and the physical world together is not a brand new concept, as scientists working on virtual reality or visualization can attest to. Even the realization


13 of such technology is not unforeseen, to one degree or another, limited number of complex, h ighly specialized applications such as flight control systems and petro chemical processing control have integrated sensory data into software control algorithms for decades. However, the introduction of pervasive computing technology to daily activities a t home, school or office in open environments available to general public opens up unlimited possibilities as well as unprecedented challenges only comparable to how emergence of personal computer utterly changed the computer industry and the world at larg e. Pervasive computing exhibits unique characteristics. In addition to the capabilities to interact with the physical world, these systems are often more complex, open, and constantly facing more uncertainties during operation. Part of these challenges is resulted from the environments they operate in. The integration with physical environment eliminates the protection of closed enclosures available to most computing systems, and the employment of diverse sensors, actuators, computation and communication de vices push the issues of lives makes it a necessity to interpret or even predict their intentions, as well as new, flexible and adaptive modalities. 1.2 Safe ty Issues in Pervasive Computing Systems Computers have been an integral part of control function units in majority of modern systems, and they now control most safety critical devices 3 For mission critical systems such as flight control software, nuclear power plant operation, and chemical plant processing, tremendous resources have been devoted to enhance the safety and reliability, usually by adopting ultra safe fail proof designs on these systems. Unfortunately, for general purpose commercial applicati ons such as pervasive computing systems, such an approach may not only be financially infeasible, but also structurally


14 impossible. Because they are dynamic and general purpose, there is no way to provide sufficient redundancies to cover all possible appli cations and potential software/hardware combinations. The primary principle in designing safe specialized systems, such as flight controller, is to ensure the process moves along as planned, no matter the circumstances. Ensuring the system follows the pro tocol and accomplishes the tasks, guarantees properties and personnel will not be harmed during its operation. To ensure the safety in pervasive computing systems, however, requires a different set of rules. The first rule is to accept failures as the norm Employment of so many different components statistically guarantees a high probability that some parts of the system are always malfunctioned during the operation. This implies the design of the system needs to assume proper functioning in anticipation t hat failures and risks will occur, and appropriately handling them when they do occur; when the scope and damage is beyond correction and compensation, the system need to be able to gracefully and safely shutdown. The second rule is to set the priority str aight. Unlike the specialized systems, ensuring the success of the processes and protocols do not translate into protection for people and properties. The safety design of systems should protect people first, properties second, and the success of process l ast. 1.3 Motivation As a new computation paradigm, pervasive computing has many unique characteristics, which both presents great opportunities and brings higher risks. Some characteristics, such as the ones listed below, prompts us to take serious conside rations regarding the safety issues. 1. The use and integration of sensors and actuators gives these systems the capabilities to interpret and influence the physical world. 2. Many systems provide services considered to be personal, and often in private and int imate settings.


15 3. Most applications are designed to be context aware and highly customizable, some even 4. Many pervasive computing systems are designed to be mission critical or provide assistive services to persons with special needs. In short, before pervasive computing can be widely adopted, we need to ensure users can benefit from the convenience of various services, without being exposed to unknown risks brought upon them by these s ame services. The extensive use of sensors and actuators allows pervasive computing systems to interpret and influence the physical world. They are capable of providing services and assistance by maneuvering electronic devices and physical objects such as appliances, robots or even dumb objects like doors. However, this capability implies that the impact of malfunctioned systems is no longer limited to loss of data, waste of time and effort or damage of computing devices; the possibility that users, bystand ers, or physical properties can be harmed is as real as the provided services and assistance. Many pervasive computing systems are intimate 4 because they have extensive interactions with users, and perform personal tasks on behalf of them. Intelligent env ironments such as smart homes 5 and intelligent vehicles 6 7 keep extensive records of their users and act upon their preferences and limitations. These systems exist in homes and cars, which are considered to be private, safe and treated with affections. Ma ny services involve our daily routines, including medicine reminder, scheduler, or even personal hygiene 5 lives, and users have high expectations and place trust on them. Failure to perform or even causing damages can result in significant impacts on their lives as well as invoking strong emotions. The semi sentient nature of pervasive computing systems allows them to be aware of grai ned user


16 information. How do we ensure such systems would not betray the trust placed by their users? first two laws can be restated as follows, 1. A pervasive computing system may not injure a human being or, through inaction, allow a human being to come to harm. 2. A pervasive computing system must obey orders given to it by human beings except where such orde rs would conflict with the First Law. Although robots and pervasive computing systems shares the same physical abilities to influence and interact with the physical world, robots are usually designed as stand alone systems, while pervasive computing system s are far more user centric and encompassing, which make these two laws even more pertinent. Certain pervasive computing systems are designed to guarantee proper actions will take place at all time, even under extraordinary and unexpected emergency situati ons. Examples include fall detection of frail people 8 fire alarm 9 and intrusion detection 10 11 Other are designed to augment disabilities and compensate the absen ce of functional skills, through maintaining or enhancing existing abilities of disabled pe ople. They are critical in establishing the being and quality of life 12 13 Examples include navigational system for visually impaired people 13 assistive Manus Robot 14 p hotographic memory review 15 and smart houses 5 14, 16 20 These systems play critical and central roles in people who adopt and rely on them. Unsafe operations, or even just improper functioning, can cause irreparable harm to users. These systems may not be in charge of airplane jets or plants worth hundreds of millions, the immediate impacts on users undoubtedly make safety a top priority.


17 1.4 Scope This research project aims at enhancing the safety of pervasive computing systems to protect against the occurrences of safety hazards caused by human an d system errors, as well as reducing the impacts of and recovering from risks that arise during their operations. In particular, this enhancement is achieved by accomplishing the following: 1. eness of various safety issues, and incorporate the detection and handling of risks into the design and implementation process. 2. Design and implementation of middleware components that can detect, prevent and handle various risks factors in the system and t he surrounding environment. 3. Introduce new software development tools that can naturally incorporate critical safety features into the end system being created.


18 CHAPTER 2 PROBLEM STATEMENT 2.1 Defining Safety ited words in the vocabulary of computer scientists. It often conveys a vague imaginary that re presents different meanings depending on the users, environments and the type of systems. In order to enhance safety, we have to start by properly defining the t safety particularly wielding a definition that is suitable for pervasive computing systems and intelligent environments. The most intuitive approach to understand safety is by investigat ing what an unsafe situation might bring. The definition of saf ety risks is often defined by a product as shown below, Safety risk = frequency of risk occurrence x damage per occurance 3 The safety of any system can be improved by either reducing the probability that a risk might arise, lowering the damage a risk might cause, or both. In the domain of computer science, many techniques capable of accomplish ing either of these two tasks have already been investigated For instance, f ault tolerance, redundancy and compensation are powerful tool s for reducing failure, while recovery and self reorganization are often used to minimize the potential damage. As such, safety in pervasive computing can be defined using the following terminology more easily understandable by computer scientists, Conformity to the expected behaviors Big Red Button (Capability to behave appropriately during emergency) Guarantee in the c onfidence level in both data and behaviors Robustness (Fail safe) o Fault tolerance o Redundancy o Availability Adaptiveness Concurrency control


19 Security and p rivacy Authen tication, authorization and u ndeniability 2.2 Objectives The ultimate objective of this study is to enhance the safety of pervasive computing systems. Such an objective can be achieved by taking steps to reduce the occurrences of safety hazards caused by h uman errors or component malfunctioning, to minimize the potential impacts should such instances occur, and to speed up the recovery so normal operation can resume. The mechanisms proposed should provide extra safety protections for users, properties and p rocesses associated with these systems. Realistically speaking, it is of utmost importance to acknowledge the impossibility to guarantee the safet y of an intelligent environment, or any regular environment for that matter. Accidents happen, people make mi L aw always looms around the corner. A glimpse of local news coverage on numerous accidents and hazardous instances serves as a reminder that despite the best intentions and most diligent efforts, the safety may be significantly improve d but risks can never be eliminated Weighing risks introduced and the cost to reduce or eliminate them is a continuous process. Since total safety guarantee is beyond reach, we identify the following attainable objectives in the order of difficulties and proactivity: 1. Cause no harm: Bringing pervasive computing systems into our lives, or a ddi ng new technology, devices and services should not be come the primary contributor of surging risks. Similar to conducting cost/benefit analysis before making business d ecisions, it is critical to assess the risk/benefit ratio to en sure additional convenience significantly outweigh the extra risks introduced 2. D etect and handl e emergency: With capabilities to sense the environment, interact with physical world and make cal m decisions, pervasive computing systems are excellent candidates to handle safety risks should they occur. 3. Avert and prevent safety hazard s: The best strategy to ensure safety is to make sure the danger would never occur. When designing a system, we shou ld strive for one that can proactively detect, prevent and manage existing risk factors.


20 For example, a house can catch fire if an absent minded person leaves the gas stove on and forgets. Deploying a pervasive computing system should not increase the chan ce of fire because of improper implementations or invalid operation instruction s. As matter of fact, it is much preferred if the system c ould monitor for and eliminate potential causes of fire hazards, or at least respond quickly should a fire start s 2.3 Challenges Safety of pervasive computing systems, particularly those deployed in intelligent environments, is a serious and critical concern. Because of their capability to influence and interact with the physical environments, the frequent and intimate in teractions with users, the proactive interventions on behalf of users, compounding with the fact that many of them provide critical and assistive services 5,8 20 result in dramatic increase in both the probability that unsafe situations may occur and the p otential damages resulted from such occurrences. Enhancing safety is a particularly tricky preposition for pervasive computing because of the inherent dynamicity, heterogeneity complexity and uncertaint y exists within the system and the surrounding enviro nment Dynamicity: Most pervasive computing systems have open boundaries. Unlike mainframes and enterprise servers which are secured in machine rooms, or even desktops and laptops have their own enclosures, pervasive computing systems make use of smart app liances, mobile devices, miniature sensors and actuators deployed all over the environment. New devices can be brought in at any time, and existing ones can be removed or failed without warning. The use of in network data processing and mobile devices mean s that not only I/O capabilities, but also computing capacity can change dynamically. The constant movement of devices, processes and users and the ensuing dynamicity of the entire system, present a serious challenge when analyzing potential risks and avai lable resources, or detecting and handling safety hazards. For


21 any safety mechanism to be effective, it has to embrace and continue functioning properly amid the dynamic changes. Heterogeneity: In order to collect data on various aspects of interest in the environment, a wide range of sensors have to be involved. Effective interaction with the physical world requires the use of a wide range of actuators. The widely adopted ad hoc communications and in network processing means the processing units within a p ervasive computing system can be vastly different too. When compared with traditional computers or network connected distributed systems, a typical pervasive computing system has to accommodate much more diverse I/O devices, highly asymmetric processing no des, and often applications and services with very different purposes and resource requirements. The heterogeneity prevents the use of generalized risk patterns in analyses, and the vastly different capability and potential safety threats associated with e ach device implies safety mechanisms have to be tailored accordingly. Complexity: The dynamic and heterogeneous nature of the systems nudges researchers to seek more adaptive and complex supporting infrastructures. Many decide to employ service oriented a rchitecture (SOA) 95 96 while others propose alternative mechanisms including brokerage based approach 21 ,55 These highly dynamic mechanisms greatly increase the overall complexity. On top of that, the sheer number of hardware devices and software artifact s involved, and the large amount of data collected, all further contributes to the complexity of the system. To propose a single safety mechanism, such as a system wide safety monitor or risk management unit, that can effectively protect all components aga inst all possible threats in such a complex system is extremely difficult, if at all possible. Uncertainty: Uncertainty about data, devices, users, and the overall status of the system in the space, is ubiquitous in pervasive computing. The availability of devices and users can change


22 in an instance without warning; the involvement of huge number of unprotected sensors without backups implies an extremely low mean time to failure (MTTF); and in many applications, there is a need to infer or even predict use unreliable. Amid the ubiquitous existence and potential far reaching propagation of the uncertainty, measures such as explicit descriptions and the status polling and reporting capabilities is cruci al in reducing the guesswork and uncertainty at both design time and runtime. 2.4 Strategy Facing the adversarial characteristics in dynamicity, heterogeneity, complexity and uncertainty, we embrace the following strategy when devising safety mechanisms. Divide and conquer: The idea of building a single overarching safety mechanism capable of protecting all components against every possible safety risk is unrealistic due to the exhibited complexity and heterogeneity. Instead, a much more manageable and eff ective proposition is to independently secure each component against perceivable safety hazards. This horizontal approach also allows protective measures to be tailored specifically for each individual component. Incorporate protection in layers: The strat divide and conquer ensures each component is safeguarded, but safety risks can still occur when individually safe proof components engage in problematic interactions, or caused by external forces beyond the control of the system exerted by nature divide and conquer horizontal, piecemeal strategy to protect the system, it is equally important to include different layers of safety mechanisms vertically, which are capable of making sure only proper inter component interacti ons can take place, and to detect and handle anomalies and hazards system wide. Externalize knowledge with e xplicit modeling and description: Most pervasive computing systems operate in extremely dynamic and uncertain environments, which require them to be adaptive and often reconstruct themselves on the fly. The externalization of the knowledge with regarding to each component and the system as a whole, using explicit descriptions, can dramatically improve the adaptability and reduce risks resulted from hi dden or incompatible assumptions. Explicitly characterizing the capabilities of each device, the features and interfaces of each service, and the preferences and limitations of each user, not only benefit the smooth operation of the system, but can also he lp users to understand the system better. Avoid, detect and handl e : A wide variety of safety risks exist, each possesses dramatically different characteristics. Some are avoidable, such as overload ing of an electric breaker, while others are not. Some can be swiftly handled once occurred such as switching to


23 backup generator when brownout takes place, while others are beyond the capability or control of the system. The design of safety mechanisms, therefore, has to support all three aspects of safety manag ement, to avoid, detect and handle safety hazards and apply appropriate actions accordingly At the design stage, the incorporation of safety practice and awareness can eliminate a majority of system induced risks; at runtime, the system should monitor fo r both identified and unidentified potential safety risks, and handle the ir occurrences to the best of its capability. 2 .5 Approach We adopt the following iterative approach to effectively enhance the safety of and within pervasive computing systems as sum marized in Figure 2 1 Conduct system analysis and create formal models to acquire in depth knowledge about what pervasive computing systems are and what they are made of: Pervasive computing systems are complex and dynamic therefore effective protection r equires identifying the common and constant backbone in these ever changing and expanding systems. Formal modeling of the fundamental elements generate a high level and abstract understanding that looks past the dynamicity and heterogeneity to reveal the e ssence of the systems to be protected for. Conduct risk analysis to identify potential safety risks: Before designing any safety mechanisms, we need to know the various types of risks, and what contribute to their occurrences. Because the systems of intere st are mostly general purpose, it is not possible to identify all use cases, and build mechanisms around the specifics. Instead, we construct scenarios demonstrating potential realistic safety hazards, then identify and model the root causes of these threa ts which are to be protected against. Design and implement effective safety mechanisms applicable to pervasive systems implemented using service oriented programming model: The system and risk analyses provide the foundation for the design and implementati on of safety mechanisms. The design strictly follows the strategy laid out above. It should include static components that prevent systems from inducing additional unjustifiable risks, and dynamic components that manage safety hazards at runtime. They shou ld be structured in layers to avoid risks from slipping through. Although the design is not meant to tie into any particular middleware, the first implementation is built upon the Atlas architecture established at the University of Florida 22 Furthermore, a software development tool is implemented to incorporate the safety aware software practice, application programming interface, and utilization of safety components in the middleware as part of the development process. Explore alternative programming mod els capable of providing a more integral approach to safety guarantee: SOA and component based approach are by far the most dominating software architectures adopted in pervasive computing. Although mechanisms proposed can be integrated quite nicely with t hese architectures to provide effective enhancement in safety, they exist more as addendums rather than as integral parts of these architectures. Exploration of alternatives leads us to devise a programming model centered


24 on context that can provide a stro nger safety guarantee with integral safety features and easier risk detection and avoidance. Figure 2 1 Research agenda


25 CHAPTER 3 RELATED WORK We next present the related research on safety issues and mechanisms for software and for pervasive computing systems in particular. Overviews on middleware architecture, programming model, and mechanisms to support context awareness ensue. 3 .1 Software and Computing System Safety Leveson proposes establishing safety modeling with soft ware engineering practice using fault tree and probability analysis. She identifies safety requirements and explores the concept of design for safety 3 Her model and practice help to shape our solution, but do not provide any immediately applicable specifi cs for pervasive computing systems. Limited studies on the safety issues of pervasive computing systems exist. A compile time semantic checking mechanism for a functional/logic programming language has been proposed for implementation and verification of s afe pervasive computing systems 23 More studies are available for safety in specific application domains, in particular, those concerning intelligent vehicles 6 7 and smart healthcare 24 Many driver assistant systems have already been deployed in luxury veh icles or commercial fleet, and more are being developed in labs across the globe. One of the primary tasks is to protect the safety of drivers and passengers. In highly complex systems such as driver assistance, solutions often come in hierarchical archite ctures. One proposal divides them into four layer: Mission layer, representing the judgment and planning functions associated with expert driver, such as planning a trip with shortest route; Strategic layer, which defines goals to be accomplished by lower layers in order to complete the specified mission within the environmental constraints, such as collision avoidance and lane keeping; Tactical layer, which devise plans and procedural functions such as motion planning; and Regulation layer, which


26 executes the lowest mechanical functions that actually directly interact with the vehicle, such as regulation, tracking and estimation 25 27 Driver assistant systems can be either assistive or interjectory. In the former case, the system performs parallel analysis to the driver, and prompts warnings or advices when danger may soon occur; in the latter case, the system intervenes on behalf of the driver, and keeps the vehicle out of danger with optimum strategies 28 An intriguing revelation comes from the breakdowns mistakes, 19% associated with bad road condition, and only 7% is caused by mechanical or system failure. Similar results with slight variations have been observed in the US, Japan and Europe 29 Therefore the main target of research in the safety of smart vehicles is to either warn drivers of potential danger or take over when accidents are imminent. Researchers have taken very diverse approaches and perspectives on this topic Some focus on human factors and usability when delivering information 30 31 formal methods and software engineering processes used in designing and certifying the safety of distributed systems used in vehicles 32 driver vigilance and collision monitoring 29,33 as well as accident and vehicular control modeling 25,28,29,34 In addition, as a recognition to the crucial role that computing systems play in vehicles, various standard and regulation bodies have either adopted or proposed guidelines, principles a nd standards on the design of human machine interface of in vehicle information system. Some examples include ISO TC 22/SC 13/WG, SAE J2364 35 and SAE J2365 36 Bohn et al. argue that healthcare is ideal as an archetypical field of research in pervasive comp uting 24 They list the requirements for such a system to be considered dependable, including availability and quality, confidentiality, authenticity, availability, security and safety.


27 High level schemes are proposed to improve accessibility and auditing c apability of healthcare systems. Other pervasive computing research projects on healthcare focus on how to offer effective assistance or streamline process of providing care 37 38 Other work investigates proper model regarding the use of clinical informati protected 39 Our goal in this study is to create generic safety mechanisms applicable to a wide range of pervasive computing systems in intelligent environments, and not limited to protective measures for systems with singular focus and use, such as automobile and hospital. 3 .2 Programming Models and Tools MPACC is an application model for programming pervasive space proposed in the GaiaOS project 40 It involves five components with distinct critical functionalit ies in pervasive computing applications. The model provides the specification of operation interfaces, the presentation dictates the output and presentations, the adaptor converts between data formats, the controller specifies the rules and application log ic and the coordinator manages the configurations. MPACC and GaiaOS follow the Model View Controller 41 paradigm, but use adaptor to transcode data from the model to formats suitable for each individual output device in place of a traditional controller. C oBrA 21 is a broker centric agent architecture. At its core is a context broker that builds and updates a shared context model which can be accessed by all the appropriate agents and services. PCOM 42 adopts a component model that explicitly defines contrac ts to describe the dependencies between components, and allows systems to adapt to changes in resources. When working in tandem with BASE, a middleware for pervasive computing, PCOM can be used to select best suitable components required by any application from among all available services.


28 Sentient object programming model is built on a flexible component based middleware that allows run time re configura tion 43 Each object in the pervasive computing space is implemented as a sentient object capable of sen sing, viewing, and reasoning about the environment as well as neighboring object s. It can also influence the world by activating certain types of actuations. Two component frameworks (CFs) play crucial role in this middleware, the context component framewo rk (CF) supports sensor fusion and rule based inference, and the publisher subscriber CF serves as the conduit between the interacting entities in the system. iQueue 44 and iQL 45 allow programmers to compose applications by deriving higher level data from l ow level raw data. Their fundamental designs are very similar, iQueue outlines the components and data flow needed to support the compositions using sample implement ation in Java, while iQL further defines a new programming language with an approach simila r to functional languages. This model defines properties and interfaces of software building blocks known as composers, and the code within each composer performs data processing to generate outputs based on inputs. Without knowing the internal details o f composers, the runtime system can advertises and binds these composers to formulate more complex applications. Every data source can either be polled passively, producing data on request, or actively pushing data whenever it become s available. These comp osers can be used to construct an acyclic di graph, often referred to as context graph in which lower level nodes are annotated with functions that generate values required by nodes higher up in the graph. Solar framework 46 48 allow s data resources to adv ertise using context sensitive names and applications to query using those same context sensitive names. Through the advertisement and query context aware applications can find appropriate data sources, and specify rules on how to


29 derive the desired conte xts from the m Solar provides a derivation mechanism similar to iQL for high level data, and a mechanism for making context quer ies A very different programming model for pervasive spaces wa s proposed 49 50 in which both the programming procedure and runt ime behavior are driven by context It provides formalization of pervasive space s and solely make s use of description logic to interpret the current state of the world. This guarantees that contexts declared can actually occur in the space and prevents con tradictory contexts from being simultaneously activat ed It also explicitly describe s the effe ct of entities in a smart space, allowing the system to detect conflicting or dangerous behaviors at compile time hence providing a safety assurance in pervasive space s at all time One of the early programming supports for context aware applications, iCAP 84 allows programmers to prototype an application without writing any code. The tool supports definition of rules using user defined inputs and outputs, and crea tion of applications adjustable to contexts associated with activity, identity, location and time. VisualRDK 85 is a high level visual programming language designed for rapid prototyping and customization of pervasive applications. It is event driven and as ynchronous, and binds functionality based on situations, persons or locations. It supports many basic programming language constructs, such as branches, loops and dynamic variable binding. Applications are created using drag and drop components configurabl e to incorporate application logic, and can be translated into executable code or executed using an interpreter. 3 .3 Middleware Architecture for Pervasive Computing T o support and manage typical heterogeneous, dynamic and complex pervasive computing system s, middleware has turned out to be a very popular and effective solution. The architectural design and implementation of these middleware has detrimental effects on the performance and


30 characteristics of systems that employ them. We next examine several re presentative middleware for pervasive computing. B ased on their own experience and survey of colleagues identify the taxonomy of mid dleware for pervasive computing. R egistration and discovery, service and subscription, d ata storage and streaming, computation sharing and context management, are identified as f ive key subsystem categories that a middleware for pervasive computing should provide 37 Gaia middleware model s pervasive computing environments as heterogeneous and mobile computing system s, and provides system level support to physical spaces 40 It supports the functions and notions in a typical operating system, such as event, process, file system and security measure. But it also support s functions specific to per vasive computing, such as context and location awareness. Component Management Core (CMC) as part of Gaia Kernel, manages the life cycle of Gaia components such as context service, event manager, or security service so they can collaborate to provide the services needed for various applications. As part of this middleware, an MAPCC application framework has also been proposed for creatin g and customizin g new applications. Context awareness is one of the major differentiating factors of pervasive computing and plenty of research work has been conducted in this arena. Context toolkit employ s a layered approach to collect aggregate s and interpret s context information 51 53 A more elaborated middleware focusing on context has been proposed by Huesbscher and McCann, which defines quality of context and trust model, while employing self configuring, self healing and self optimizing adaptation for different applications 54


31 RCSM is a middleware that provides both context awareness as well as ad hoc communications between applications to support more complex context aware collaborative behaviors 55 C ontext information retrieval in RCSM is conducted using two separate mechanisms. T he application specific adaptive object container (ADCs) wrap around a normal software application object and provide a context sensitive interface for access ing contexts of interest specific to each application. A context sensitive object request broker for service and device discovery allows application transparent ad hoc communications b etween objects. With compiler support for context sensitive interface description language, the implementation of application logic and context information retrieval can be separate d into orthogonal task s. Other middleware focuses on different aspects of s ystem support s for pervasive computing system and takes di verse approaches. For instance, RUBI is a middleware that supports service discovery specifically for context aware applications. By dividing nodes into proactive, less mobile region and reactive, o n demand region s the design of RUBI draws inspir ation from how ad hoc routing protocols disseminate service information and route requests 56 This adaptability comes at the cost of periodic maintenance mes sages and not able to cache status of and data fro m the services. KMX not only adopts middleware to enhance horizontal cooperation, but also modif ies kernel to allow cross layer coordination 57 The coordination and decision making module in the middleware collects resource information from within the node as well as the network traffic and information about other nodes, in a way similar to the control module of transcoders. The modified kernel intercepts the incoming and outgoing data and control commands, which allows transient object s in the middleware to provide additional functionalities such as filtering or security features. This middleware grants lower level system control so many ideas from


32 distributed multimedia delivery with quality of service can be applied As compared to other middleware, i t provides a different perspective on adaptation of pervasive computing system in dynamic distributed environment s With Scooby middleware architecture and lang uage, Robinson and colleague ta k e a different approach by defining a language that focuses on serv ice composition 58 Employing a policy compiler, the middleware turns policy specifications into composed services. Furthermore, the available services and their functionalities are described in terms of ontology. Therefore, the policy manager can route eve nts and requests to these services based on some predefined precedence order. 3 .4 Context A ware Computing Context aware computing is a paradigm in which applications can discover and take advantage of contextual information. This could be temperature, time of the day, location or activity of the user, etc. Context is any information that can be used to characterize the situation of an entity. An entity is a person, place, or object that is considered relevant to the interaction between a user and an applica tion, including the user and application themselves 59 In order to simplify the development of pervasive applications, effort has been placed into developing solutions that enable easy use of context. There are two main approaches: libraries and infrastruc ture. A library is a generalized set of related algorithms whereas an infrastructure is a well established, pervasive, reliable, and publicly accessible set of technologies that act as a foundation for other systems. A co mparison between the two has been p ublished 60 The Context Toolkit 52 53 provides a set of Java objects that address the distinction between context and user input. C ontext s consist of three abstractions: widgets, aggregators and interpreters. Context widgets encapsulate information about a single piece of context,


33 aggregators combine a set of widgets together t o provide higher level widgets and interpreters interpret both of these. EQUIP Component Toolkit (ECT), as part of the Equator project, takes an approach more similar to distributed d atabase 61 Representing entities in the smart space with components annotated with name value pair, property and connection, ECT provides a convenient way to specify conditions and actions of the applications, as well as strong support in authoring tools, such as graphic editors, capability browsers and scripting capabilities. R ehman and colleagues proposed architecture for interactive context aware applications 62 following the Model View Controller paradigm. Their architecture address three usability issue s in context are made without communicating the assumptions on which those inferences are based; inadequate feedback to allow users evaluat ing stripping the control f rom users The no tion of Semantic Web services 63 is that by giving a description of a web service tasks such as discovery, invocation, composition and interoperation can be automated The Semantic Web makes use of description logic to describe a service Description logics are knowledge representation languages tailored for expressing knowledge about concepts and concept hierarchies. An agent can use this description to reason about the behavior or effect of the invocation of a web service. In more way t han one, the context driven programming model 49 has drawn inspirations from this notion of Semantic Web services. The SOCAM architecture 64 is a middleware that makes use of ontology and predicates. The re is an ontology describing each domain of interest. By making use of rule based reasoning we can then create a set of rules to infer the status of an entity of interest. It shows that ontology


34 can be used as the basis of reasoning engines, but such engines are not suitable for smaller devices due to the com putational power required. 3 .5 Atlas Architecture Most researches have been focused on either sensor networks or middleware, and this disjunction between sensor platforms and middleware creates a barrier to seamless development. The Atlas architecture dev eloped in the Mobile and Pervasive Computing Lab at the University of Florida, addresses this problem by providing a scalable network enabled, service oriented middleware in which numerous and heterogeneous sensors and actuators can be automatically repres ented as software services upon activation 22 Application developers can then use these services and associated utilities to manage devices and compose applications without the detailed knowledge of the physical characteristics of the devices or the sensor platform node. The Atlas a rchitecture, which includes both the middleware and the sensor platform as shown in Figure 3 1 provides an all around solution to the development and deployment of pervasive computing systems.


35 Figure 3 1 Layered Atlas architecture


36 CHAPTER 4 ANALYSIS OF PERVAISV E COMPUTING SYSTEMS The first step in enhancing the safety of any computing system is through system analysis. There will be no effective safety measures or suitable programming model until we acquire a thorough understand ing about the components to be protect ed and where the risks may arise It is important to start by surveying existing systems, identifying the uses and risks associated with each, and getting to understand the fundamentals, s uch as the common components among various establishments. 4.1 Survey of Pervasive Computing Systems T he intended use and application domain of pervasive computing systems are highly diversified that it warrants conducting a survey to understand their comp ositions, how they are used, and the kind of safety risks may occur While some are application specific that provide s a well defined service under a very specific context, others are more generic which can be deployed any where or designed to be integrated with other systems. By s urveying existing prototype s and real world deployments we can examine the breadth of this diversity, identify the common and specialized components employed, as well as the possible use cases and plausible risky scenarios A list of representative applications in various domains is presented as follows. 4.1.1 Location Aware System: Bat Bat is an indoor location aware system jointly developed by AT&T Research Cambridge and the University of Camb ridge 65 A large scale real world de ployment and trial has been conducted over two years inside a multi story office building A number of location aware applications have been developed using Bat, to create a model of the real world in which object s are annotated with position, orientation and current state. Since these applica perception of the environment, the y are also known as sentient computing system 66 Researchers


37 are particularly interested in the accuracy and privacy issues with respect to these location aware appl ication s. 4.1.2 Smart H ome s: Aware Home, Gator Tech Smart House, iDorm Smart home is among the most studied categor ies of pervasive computing systems. Often e mploying a large number o f sensors, smart appliances, and intelligent, context aware application s smart homes provide assistive, comfortable and secure environments for the residents. Typical applications include light and climate control, healthcare and remote monitoring, security surveillance and integrated communication services. T here are distinct technical approaches in enabling these applications as demonstrated in the following representative examples The Aware Home at the Georgia Tech, is one of the earlier smart home establishments I t provide s an experimental environment for pervasive comput ing in support of everyday lives, or more specifically, the part of lives that are centered and around homes 67 The ir main focus is to study HCI and modality related issues The Aware Home is capable of gathering information about itself as well as the whe reabouts, activities and conditions of its inhabitants. T herefore it poses as a critical concern regarding whether the residents have the knowledge and control over the distribution of this information. The Gator Tech Smart House (GTSH) 68 at the Universi ty of Florida is a collaborat ive effort between Computer & Information Sciences & Engineering Department and College of Public Health and Health Professions. It creates an assistive environment supported by pervasive computing technologies allowing elderly or people with disability to live independently. The main focus is to reduce efforts required to develop and deploy pervasive computing systems. With Atlas architecture at the core of GTSH, and its modular and extensible middleware, it can automatically i ntegrate a wide range of deployed sensors and actuators into the system as


38 software entities. A number of assistive applications have been developed and deployed, including Smartwave an automatic food preparation service utilizing RFID tags and predefined recipe s, and keyless entry system a security feature that identifies visitors and allow residents to control the door s remotely. iDorm locates in a student dormitory at the University of Essex that has been retrofitted as an inhabited intelligent environ ment test bed 69 70 Embedded intelligent agents, network infrastructures and human technology interfaces are keys in realization of ambient intelligence that support s student s ever yday lives. The research project favors distributed intel ligent agents and fuzzy logic when creating s mart environments. A user centric framework has been established by using this test bed to study usability issues including historical, socio political and 71 4. 1.3 Interactive Museum: Exploratorium Costa Aquarium Hypermedia Guide The Hewlett Packard Laboratories utilize s pervasive computing technology to enhance in a museum 72 The Exploratorium, a large scienc e museum in San Francisco, is incorporated with a nomadic computing infrastructure to allow visitors to switch between virtual and physical interactions when visiting various exhibits on display. It serves as a real world test bed for usability studies on pervasive systems in interactive museums and discovers issues regarding the compactne ss of PDAs, demands on user s attention, lost in hyper reality and problems with browser interface. Costa Aquarium Hypermedia Guide 73 aimed at understanding how pervasive computing can support a museum visiting experience Researchers at University of Genoa build a fully operational, reliable, and robust tour guide, consisting of a mature and reliable palmtop computer equipped with hypermedia software and deploy these equi pments in a real museum Costa Aquarium at a cost of 4.50 per rental The main feature of the guide is to provide


39 multimedia content associated with species exhibited in the tanks, and a map guiding user through the aquarium. Comparing with Exploratorium and other interactive museum projects, Costa Aquarium Gui de provides insights about interface design and usability of electronic tour guides, but does not provide advance features in pervasive technology, such as automatic location detection. 4.1.4 Smart Laboratory: Labscape, e Science The e Science program is a research initiative in UK to lend pervasive computing support to computational intensive sciences 74 It convert s laboratories to pervasive computing environments, hence allowing data collected in the lab to be captu red and published automatically, informa tion generated to be shared, combined and compared with other labs on demand, and the provenance to be readily discovered. It provides guidance to researchers regarding the process and required time of the experiments As part of the project, an evaluation of its usability is performed following the Process, Outcome, Affect (POA) model. Labscape aims at creating smart environment for cell biology laboratory 75 It focuses on the procedural guidance to various experiments. Using a graphical interface ( sample flow graph or SFG ) to design the experiment, it creates a workflow to guide researchers through the preparation, execution and documentation phases. This approach grants researchers total control to design and run various experiments using Labscape and it s advance features provided by pervasive computing technology. To simplify the design of Labscape and reduce uncontrollable factors during the experiments, it takes an approach to acquire direct user inputs instead of gestures or utilizing AI for automatic learning. 4.1.5 Context aware Health Care : iHospital Constructed to be a hospital scheduling system support ing the often intense coordination of various operations in a large hospital iHosptial is one of the few real world deployments of


40 pervasive compu ting systems 76 This coordination is made possible by pervasive technologies that are capable of location t r acking, context aware, and offer multitude of interactive displays. The de ployment of this system at a Danish hospital i nspires intriguing discussi ons o n real world deployment issues related to hardware software and user settings. For instance, the researchers offer insights on various issues including the cost, space, power consumption, safety issues of hardware; debugging, upgrading, integration a nd security issues of software; and usability, learning, privacy issues related to user settings. 4.1.6 Telematics: Data Protection Framework Project 54, IT Cruiser With the emergence of telematics, infotainment and sensor network technologies, the autom platform to a pervasive space in which all processors and sensors are connected together 77 In tegration of emergency, roadside, and concierge assistance allow the new generation of smart vehicles to introduce a new in vehicle consumer experience. To examine and assess the nonfunctional aspect of vehicle performance, Patterson proposed automotive SP UR as evaluation metrics that include security, privacy, usability, and reliability 78 Several projects focused on various aspects of automotive SPU R 78 By making use of multi tiered security architecture on top of a trusted computing platform, the Data Pr otection Framework focuses on the security and privacy of data exchanged between providers of telematics service and vehicles 79 Pervasive computing technologies, which enable dynamic user interactions, further complicate the automotive reliability issues, which lead to an investigation on how reliable software architectures can be applied to support runtime enforcement of software reliability without strict control over user actions 79


41 Researchers of t he Project54 partner with the New Hampshire State Poli ce to improve the usability of electronic devices in police cruisers by integrating stand alone devices under a single user interface 80 The IT Cruiser project a joint venture between DaimlerChrysler and Sun Microsystems provides drivers and passengers with infotainment and telematics services such as email checking, web browsing and navigational assistance, through a combination of Java and Jini technologies implemented in a prototype vehicle 81 4.1.8 Outdoors D eployment : Great Duck Island GUIDE P er vasive computing systems deployed outdoors can be found in various civic and military applications; habitat monitoring, environmental observation and forecast are examples of civic application, while battle field surveillance and enemy tracking are the rep resentatives of their military counterpart Regardless of what the application is they are often based on data collection over sensor network s Deploy ing large number of sensors in outdoor environments enables long term data collection at scales and resol utions that are difficult, if not impossible, to obtain otherwise. The habitat monitoring project in Great Duck Island is a joint research project between University of California at Berkeley and College of the Atlantic, Bar Harbor, Maine 82 A hierarchica l wireless network structure is established by connecting numerous of Mica nodes that monitor the seabird nesting environment, and collect data on light, temperature, infrared relative humidity and barometric pressure, and it also detects phenomena such a s acceleration/vibration, weight, chemical vapors, gas concentrations This study addresses several important design issues, such as sensor network longevity, data sampling rate and data archiving capabili ties. Another outdoor system is designed to operate in urban environment and provides a very different service. GUIDE is an intelligent electronic tourist guide that utilizes location and personal contexts to provide information and services to its users 83 Cleverly considering the


42 scale of the geographic areas covered, GUIDE uses transmission range of WiFi hotspot as a information. It also gathers statistics on user acceptance and various HCI choices regarding the desi gn of its interface. 4.1.9 Comparisons and Discussions These pervasive computing systems are designed to be deployed in environments ranging from a single dorm room to the entire city, and from natural to urban environments. Some are application specific, while others offer generic infrastructure for integrating a variety of services. intentions. An even greater parity exists in terms of sensors, actuators (if any) a nd contexts the systems are designed to process and handle. Some attempt to integrate existing systems and services, while others aim at providing new capabilities which were not available without pervasive computing technology. Some commonalities exist am id these hugely diverse systems. They all employ sensors to (ubiquitous) computing is supposed to create invisible technology that is fully integrated into enviro nment, it appears visualization of collected data and design of suitable human computer interface have become at least one of the major foci in all these research projects. Comparison on the purposes and primary characteristics of these systems is shown i n Table 4 1 through Table 4 3 The information collected in this survey offers invaluable information for the system analysis, and provides insights on how to proceed with formal definition of programmable pervasive computing systems.


43 4.2 Commonality amon g Existing Pervasive Computing Systems The information summarized in Table 4 1, Table 4 2 and Table 4 3, a s well as others collected in our survey on existing systems, provides an excellent starting point for our system analysis It allows us to take a clo ser look at the compositions and features of these vastly diverse systems, and define what a pervasive computing system is, as well as what its fundamental elements are based on the commonality among the m Objective and application domain: There are few c ommonalities between objectives and application domains of these systems. Ranging from experimental systems 65 ,74 75,81 prototypes built for usability studies 67 ,72 73,83 to real world deployments 68 70 76,80,82 ,86 they offer easier to use integrated inte rfaces of existing systems, improved processes and experiences, or new and enhanced capabilities and services. Few clues can be extracted from these distinct objectives and application domains. However, each is designed to fulfill specific objectives and a ccomplish predefine tasks often known as services to users. Employed devices: Although the number, complexity, and availability of devices compose of each system vary, all pervasive computing system employ sensors, and depending on the objectives, many als o employ actuators. No matter what the make and type, systems interpret the surrounding physical environment through sensors, and interact with the environment by manipulating actuators. More complicated devices, such as smart appliances, have the ability to both sense and actuate. User interaction, involvement and intention interpretation: Except very few deployed outdoors, most pervasive computing systems interact with users. The extent of the interaction, however, varies from system to system. Some respo nd to regular inputs and selections from users as regular applications and web services do, albeit often with wider array of input devices, such as push to talk type of microphone, or switch and button next to an exhibit or on a mobile


44 device. Most context limitations. Locale and environment: Systems are deployed in a wide variety of environments. They can be deployed indoors, outdoors, or in other closed space such as vehicles. The environments which they are designed for, have great impacts on everything f rom the system architecture, sensor and actuator selection, network protocols to the mode of operation. An analysis of a system cannot excite the resources (or the lack of) and attributes of its environment. System architecture: By nature, pervasive comput ing systems are more distributed than centralized. However, in the majority of the systems we surveyed, there is almost always a centralized server that anchors the entire system. Whether it is where services are brokered, content and collected data stored or where resources are managed and queries are answered, even in systems that employ sensor data fusion and aggregation, in network processing, and ad hoc routing, there is a central server or gateway. Software architecture: In contrast to system archit ecture, there is no such common denominator regarding software architecture. Application is usually the key that dictates how software is structured. Service oriented architecture is popular among generic platforms, while other systems take data centric, c ontext driven or workflow like approaches and all have demonstrated their effectiveness for their specific target applications. Network: All pervasive computing systems are connected via network, although the technologies and protocols used are very differ ent. 802.11 wireless network is popular when mobile devices are used, but wired, cellular, Bluetooth and proprietary are all viable options. Some applications even use a mixed of different networks. The important observation is that


45 despite this diversity, most choices are transparent to users and tasks. For certain applications that employ resource stricken entities, especially those using ad hoc sensor networks, a power and bandwidth efficient protocol for a particular application is an important part of the design. However, when taking a top down perspective and concentrate on the application, designers can often assume the chosen underlying network technology works, and concentrate on the high level application logic design. Context: As mentioned earlier context is one of the differentiating factors of pervasive computing. Its use, however, is not mandatory. For applications that focus on data collection or process modeling, context is not a primary concern. However, for a system to be truly invisible an d calm 1 contexts allow the system to be polymorphic, and adapt based on the time, place and conditions of the system and users. There are a large number of different contexts used in different systems, and the context of interest often depends on their ap plications. However, the common theme is that in context aware computing, context often serves as the condition to define and determine the appropriate behavior of the system. 4.3 Four Fundamental Elements The discussion on the commonality of attributes, f eatures and functionalities of existing systems lead s to the following operational definition of a pervasive computing system : A pervasive computing system employs a collection of distributed devices to provide useful applications and services to its user s, within the confine of limitations posed by the environment, available Taking a top down approach from the perspective of application, we observe that network design belongs to the lower level enabling mechanism, and so is the system architecture. Certain choices and designs may prove to be more favorable or disadvantageous but the applications and end users are usually oblivious of their existence. The software architecture is something behind the scen e, a preexistent design step and post existent categorization scheme, which are composed


46 of various software entities to provide specific services and fulfill predefined objectives in the application domain. It is the collective map of composition that det ermines software architecture, and the objectives reflect the expected collective deliverance of every single component in the system, user actions included. Context is a higher level concept that summarizes and interprets sensor readings, status of the en vironment, and co nditions of user. As far as application s are concern ed context is merely a mean to achieve the objective, rather than the core of the system. T hrough these discussion s and distillation s we can now identify the fundamental elements in any pervasive computing system: device service user and space ( Figure 4 1 ) Device: The capabilities to interpret and interact with physical world starts with devices. T he y are the I/O devices that bridge the gap between the physical world and digital realm Although the complexity, capability, size and other attributes may vary, a device can al ways be classified as either a sensor or actuator. Sensor acts as the source of data which report s the status of the surrounding environment or the device itself bac k to the system. Actuator functions as the recipient of commands, w ith which the system issue instruction s are translated into certain action sequences and carried out accordingly. More complicated devices such as smart appliances or robots, which are capa ble of submitting data as well as receiving commands, can be considered as a combination of sensors and actuators. Service: Service is at the core of all pervasive computing systems. 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 expect the premeditated favorable outcome or useful functionality to be delivered upon the activation of software artifact s or systems. These functio nalities and outcomes can be deliver ed by a stand alone software artifact or in coordination with others as a group We use the term service to describe the


47 collection of software 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 dynam ic 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, attempts to model human behavior is laborious but yet rarely generate any accurat e 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 automati on Users are also the single most risky factor of all, more danger is caused by the carelessness, ignorance or misunderstanding of users than any other problems i n the system. 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 researchers 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 them selves a nd between them and users. This assumption often leads the programmers 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 services, de vices and users as well as the interactions between them; side affects usually cannot be captured by devices or


48 services, but can be described by measurable changes in a space. Based on functions, social contexts and the locale of a space, there are differ ent 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 r oom. Further investigation on the operations of existing systems reveals the patterns of interaction between these four fundamental elements, which can be summarized as Figure 4 2. Table 4 1 System objectives of representative pervasive computing systems System Objective(s) Bat Large scale deployment and experiment of context aware computing (location). Aware Home Experimental environment for pervasive technology in home environment, particularly in HCI and modality. Gator Tech Smart House Assistive e nvironment for elderly and persons with special needs, focusing on deplorability and programmability. iDorm Test bed of intelligent learning and adaptation mechanisms using embedded agents. Exploratorium in a science museum using electronic guidebook. e Science Chemistry Lab Translating the Chemistry Lab Book into a Pervasive Computing Lab Environment. (Process driven using tables) Labscape Capture formal, detailed representations of laboratory procedur es as the work is performed. (Workflow driven using sample flow graph (SFG)) iHospital Support the often intense coordination of operations in a large hospital (providing location tracking, context awareness, large interactive displays, and mobile phones) Project 54 Integrates electronic devices and its speech based user interface in cruisers to allow officers operate them safely IT Cruiser Develop in vehicle computing systems that provide safety and control systems needed to operate the vehicle and oth er additional functionalities such as information and entertainment. (using speech interface and enabling e commerce) Great Duck Island Apply wireless sensor networks to real world habitat monitoring. (allow in network data aggregation and disconnect mode ) GUIDE Investigate the provision of context sensitive mobile multimedia computing support for city visitors (also allow disconnect mode)


49 Table 4 2 Sensors, actuators and user roles of pervasive computing systems Sensors Actuators User Involvement Us er Intention Bat Bat wireless tag & ceiling mounted receivers Not directly, but can call API to implement location aware applications. Yes, movement tracking and use Yes, based on movement and location Aware Home Numerous and diverse sensors Various, por trait, Bluetooth tag, home theater, etc Yes, movement, gesture, command, review and interact Yes, gesture Gator Tech Smart House Numerous and diverse sensors Various, Large Number Yes, command, interactive, movement No, explicit commands iDorm Numerous a nd diverse sensors such as temperature, occupancy, humidity, and light level sensors Various, door actuators, heaters, and blinds, robots, portable devices Yes, multiuser, remote control Yes, fuzzy logic used for automatic learning Exploratorium RFID rea der No, information only (on web site or PDA) Yes, user initiate physical hyperlink No e Science Chemistry Lab No, only receive input data from users No, record data only Yes, user input and read data No Labscape Not necessary, can be incorporated, such as bar code or RFID scanner No, record data only Yes, user input and read data No iHospital Bluetooth dongle No Yes, user interaction and commands No Project 54 Video, audio, radar, barcode reader Yes, video recorder, police radio, siren and light Yes, u ser interaction and commands No IT Cruiser GPS receiver, smart card reader Yes, media control and communications, remote intervention of home environment and everything attached with home Yes, user interaction and commands No Great Duck Island Light, tem perature, infrared, relative humidity, and barometric pressure, additional sensors possible No No, not after initial configurations No GUIDE Uses Wifi access range No Yes, user interaction and commands No, explicit commands


50 Table 4 3 Primary character istics of representative pervasive computing systems Location System Infrastructure Basic Software Unit Network Context System Support Bat Indoor, office building Corba + Oracle DB, centralized API from World Model Wired network Location Supporting archi tecture Aware Home Indoor, Home N/A N/A High bandwidth wired + wireless network Person tracking location, health, facial expression N/A Gator Tech Smart House Indoor, Home OSGi, centralized OSGi service Wired, wireless, signal over power Various, locati on, movement & other high level contexts SOA, explicit programming iDorm Indoor, Dorm Hierarchical gateways, XML formatted query agent Lonworks, 1 Wire, & IP network 11 parameters, including time, light, temperature, posture, window, user activity Intell igent agent Exploratorium Indoor, Museum, Centralized content server, portable PDA device, HTTP Web page wireless Proximity to exhibits Cool Town, HTTP based e Science Chemistry Lab Indoor, Chemistry Lab Centralized storage of data, with Tablet input Da ta entry wireless No database Labscape Indoor, Cell Biology Lab Centralized database, with Tablet input Procedural information Wired & wireless network No, Labscape database iHospital Indoor, Hospital Central server running context aware infras tructure, Activity based schedule/ event Bluetooth, Wifi, GSM Location/proximity, activity & status Java Context awareness framework Project 54 Vehicle Integrated Embedded PC Component Object Model (COM) Digital radio link, Wifi, Intelligent Transportation System Data Bus to peripheral No IDB data bus, proprietary messaging IT Cruiser Vehicle 4 single board computer as communication gateway & provide human machine interface XML description, OSGi service Wifi, cellular wireless Internet Locat ion, person identification JVM, JINI Great Duck Island Outdoor, wild Multi tiered, sensor patch network, Field station (db & gateway), data service time stamped readings, sensor health status & metadata Wireless network, Internet connection, ad hoc networ k No Database and in node storage GUIDE Outdoor, city Hierarchical, cell server & centralized web server Hypermedia (HTTP) WiFi personal context (interest) & location Web server


51 Figure 4 1 Four fundamental elements Figure 4 2 Interactions between four fundamental elements


52 CHAPTER 5 FORMAL MODEL OF PERV ASIVE COMPUTING SYST EM Complete knowledge on pervasive computing systems has to begin with recognizing what each element of the system does. A formal model and description allows us to comprehend, in a clean and abstract fashion, how various services and devices, including both sensors and actuators, interact with each other, and how users and space provide guidance and limitations so desired out comes can be achieved 49 However, for such a model to be practical, it has to consider, in addition to the basic functions, the real constraints critical to the effectiveness, completeness and safety of the system. It is only through this analysis can we t ruly gain insights about the essence of what a pervasive computing system is, and formulate the best protective strategy against safety hazards. 5.1 Formal Model of the Fundamental Elements 5.1.1 Observing the World with Sensors We consider our world of i i where D i is a domain, within the bounds of the space, that is observable by sensors. We will use u U to denote aspects of the current state of the world. Sensors provide data about the current state of affairs. A smart space typica lly contains many physical sensors that produce a constant stream of output in various domains. As this data is consumed by the smart space, each physical sensor can be treated as a function the space can call to obtain a value. However, this works only i f there are corresponding sensors to cover every single domain of interest D i in the entire space. The reality is, due to the limitations in the availability and capability of sensors, it is not always possible to sense everything we want to know. Without a thermometer, the system cannot retrieve the current temperature; a location system with a


53 resolution of 1 meter cannot determine the exact location of a person within a one centimeter error margin; a video camera will not be able to capture the heat sign ature in infrared spectrum; and a light sensor in the lobby at the ground floor reveal little about whether a lamp in a 15 th floor apartment is too bright. On top of that, a sensor may malfunction or be improperly calibrated. Assuming the reliability issue of sensors is being taken care of by the system, using techniques such as virtual sensor 87 88 A sensor can only be deployed at one single location, which determines the area it can effectively collect data from. We can model a sensor with its practical l imitations on sensing resolution and operational range as follows: Definition 1 (Sensor) A sensor is a function that produces an output at a given time in a particular domain. Assume sensor j is capable of collecting data in domain D i with resolution of r es i j and j is deployed at p j (x j y j z j ) to collect data that is representative of the condition within a sphere S j centered at p j in an unobstructed space. f i j : U D i {D i | D i {min( f i j ) + k res i j } k N D i

54 action planning. In order to get a complete understanding of the system and its limitation, it is crucial to understand, however, in the real universe, there are plenty of phenomena that cannot be observed or comprehended due to the lack of equipments or knowledge. Definition 2 (Insensible universe). Beyond the observable and well defined universe U, there are h appenings and occurrences that are insensible by the system, and collectively, we define them as the insensible universe can be described in terms of the all encompass universe U real which include all domains, whether they are sensible or not: = U re al \ U = {x | x U real f such that f: x D k } {x | f such that f: x Di ( x >max(f) x S j p j P where P is the set representing locations of all sensors, and S j are the sphere centered at P j Insensible universe describes the limitation of our existing system in terms of the availability, operational range, resolution and spatial distributions of sensors. If the system cannot sense it, it cannot perform any meaningf ul operation, but that is ok. It merely indicates that if we want to perform any actions in either the sensing capabilities or the knowledge will need to be expanded so it can be annexed into U. 5.1. 1.1 Defining and Interpreting Context Raw sensor data is the first step in observing the physical world, but we would like to work with higher lev el information that describes the state of the world. For instance, the term Smoggy can better convey the sense of air pollution to people than 9 ppm of Carbon Monoxide while carry enough information to trigger actions in pervasive computing systems. A na tural choice for describing knowledge is to use description logics. Using description logic we can define an ontology that describes the smart space. We will restrict ourselves to taxonomic structures, and


55 therefore will have no need to define roles. The l anguage L we define here is similar to ALC 89 without roles. Throughout the following discussion, we will closely follow the definitions of ALC language a nd the description logics in general. Definition 3 (Taxonomy) Con t ext descriptions in L are formed usi ng the following syntax rule : Given contexts C and D: C, D AC | | | C | C D | C D where AC denotes an atomic context. Apart from describing con t ext s we need to have a way to interpret these con t ext s, so we can interpret the state of the space u U. Definition 4 (Interpretation Function). We define the interpre tation function I as follows: I : C U Atomic con t ext s are those directly associated with sensor readings, and not defined in terms of other con text s. For instance, we can define the atomic cont ext s S mokey Clear Smelly and Fresh The first two can be di rectly observed by a smoke detector and the last two can by a chemical sensor. Definition 5 (Atomic Context). We define an atomic context AC as follows: AC {C | f i f i I 1 :C Di} Once atomic contexts are defined, w e cou ld then construct derived con t ext s, such as Murky_Air = Smokey Smelly Con t ext s that are defined in terms of other contexts are called derived contexts, therefore, DC {C | C AC}. De finition 6 (Interpretation of Context). We can interpret contexts as follow s, I ( ) = U I ( ) = I ( C ) = U I ( C )


56 I ( C D ) = I ( C ) I ( D ) I ( C D ) = I ( C ) I ( D ) We would also like to specify how a conte xt or group of contexts relate s to another. T here are two ways of declaring relationships between two contexts. One is the inclusion relation, where some base context is a component of a larger composite co ntext (e.g., the base contexts Smoky Air and Foggy are included in the composite context Smoggy ). The other is the equivalent relation, used to resolve ontological issues where the same context has multiple names. Formally these relations are defined as: Definition 7 (Context Relations) Inclusion and equality are defined as follows: Inclusion : C D, interpreted by I ( C ) I ( D ) Equality : C D, interpreted by I ( C ) = I ( D ) The de scription of how a set of con t ext s relate to each other is called a terminology or T Box. A terminology T is a collection of inclusions and equalitie s that define how a set of con t ext s relate to each other. Each item in the collection is unique and acyclic. A n interpretation I that interprets all the atomic con t ext s will allow us to interpret the entire taxonomy. 5.1. 1.2 Current State of the World Interpretation of the curren t state of the world is straightforward. We identify whether the current state of the world is a member of any concept. In other words, to verify whether u U satisfies concept C we check that I ( u ) I ( C ) The interpretation of the current state of the space leads us to the current active context: Definition 8 (Active Context) The active context of the space R: U 2 C is: R = {C | I ( u ) I ( C i ) } operati onally, R = I 1 f( u ).


57 Much of the related research takes different approaches to derive higher level information. Most sensor networks in the literature make use of a hierarchy of interpretation functions, often refer red to as context derivation 45 46,90 which take as input the readings (or history of readings) from sensors and produce a new output value. We avoid these derivations because there is no guarantee that the derived functions will follow the consistency rules as specified by description logic. The inconsistency implies that contradictory or invalid (undefined) context states could arise, introducing potentially dangerous situations. 5.1. 2 Influencing the World with Actuators Actuators allow the smart space to affect the physical world. We model the actuators as a set A with elements a i A Our model assume s that while an actuator is turned off it has no effect on the world. In this sense, an actuator that is off is the same as an actuator that does not exist in the space. Every actuator in the space has certain intentional effect s which are the goal s we intend to achieve with activation of the actuator. Programmers specify the intentional effect by defining how activation of the actuator will affect the state of the pervasive space in other w ords, given the current state, to what new state wil l the space transitions into when the actuator is turned on. Similar to sensors, actuators also incur limitations such as their operational range and precision, and conditional clauses should be included to properly describe them. For actuators, however, a more prominent constraint occurs because of unexpected effects caused by the environment. We can now formalize the intentional effect of an actuator as follows: Definition 9 ( Intentional Effect of Actu ator ) An intentional effect g a of an actuator a is the set of states that can possibly arise due to invocation of that actuator and is composed of two independent components, the controlled effect h a and random effect e : g a = h a + e g a : U 2 U


58 In partic ular, assume u U is the current state of the world, then the next state of the world U can be described as : a (u) = h a (u) + e() The controlled effect h a () is deterministic. It describes the expected transitions of the space from one state to anoth er when actuator a is activated. Assuming an actuator a with a resolution of res a is deployed at p a (x a y a z a ) and the effects are observable within a sphere S a centered at p a in an unobstructed space, then h a can be modeled as follows: h a : U U h a (U) = { y | y { min( h a ) + i res a } i N y < max( h a ) } | g a ( u ) g a ( u pa )| S a The random effect e () represents the effects caused by uncontrollable factors in the environment, including user actions unexpected events and the natural changes in the environment itself. As e() is random and uncontrollable, it has made intentional effect g a to become non deterministic Formal definition and further discussions on e() will be presented in Definition 18. An actuator may have more than one intentional eff ect. For example, turning on a vent can be used both to improve the air quality and raise the overall power draw. The function of controlled effect h a () describes what users expect from an actuator. Many actuators can only affect the space in one direction but not the reverse. For instance, a heater can only make the space warmer, and a light bulb can only brighten the room. This directional characteristic can be properly described by choosing appropriate h a () Since h a () takes current conditions as input, whether an actuator has an accumulative or independent effect can also be specified accordingly. Notice that for each actuator a there is a possible range for its controlled effect between min(h a ) and max(h a ) However, due to the environment effect e() t he overall intentional effect is not bounded by the range of h a For instance, when a heater is activated, the controlled effect states that the room temperature is expected to be somewhere between 50 and 90 However,


59 if a window breaks during the snow s torm, the room temperature may plummet to the freezing point, which is outside of the range of the controlled effect. In majority of cases, when an effective actuator a is activated, we expect h a to dominate the outcome g a unless there is an extraordinary event. However, depending on I even small variance caused by e() may be enough to make the system interpret the space as a different context. On the other hand, when a is deactivated, meaning h a () = 0 then the outcome is dominated by the environmental e ffect e() We would like to point out two subtleties about actuators. First, we assume the current status of any actuator itself, such as whether the light switch is on or off, is available to the system. Essentially, this allows statuses of actuators to b e sensed and described as an atomic context. Second, unless there are corresponding sensors in the same domain and locale, the effects of an actuator may not be observable. This is high tech equivalent to the ancient Apart from observing the space we are also controlling the space using actuators. Within a smart space, users and the system can perform sequences of actions by turn ing actuators on or off. Definition 10 ( Statement Sequence ) Given a set of actuators A a statement sequence S also known as a s equence of actions is defined as follows: S ::= a i | i | S 1; S 2 Where a i turns actuator a i A on, and i turns actuator a i off. W e also denote action prefixing that w e first perform statement S1 and after which we execute the remaining statement S2.


60 5.1.3 Enrichin g the World with Service s A service is a group of software artifacts E (or a single software artifact) that when acquired necessary resources F can take series of actions as specified by the service logic embedded in E to deliver the expected goals G D efinition 11 (Service) A service v V can be described by the following tuple: v := < E; F ; G > w here E = {software artifact e i }, composed according to the following LL(1) grammar, e ::= instruction instruction::= statement; | instruction; statement; | if (context) instruction; | if (context) instruction else instruction; | while (context) instruction; where statement is a sequence of action as defined in Definition 10 and context C F = {x | x A V } is the collection of dependent resources that the service v req uires to deliver goals G. G C i s the expected goal, as defined by a set of contexts, to be delivered by v 5.1.4 In habit ing the World as a User To model the user we roughly follow the belief desire intention model 91 in the sense that the user observes the state of the space and, based upon this information, commits to a plan of action. Desires are the set of preferences about the state of the world. These preferences dictate how the world should be at that given moment. Belief is the current ob served state of the world, interpreted by taxonomy.


61 Intention i s the action plan to which the user commits. In a smart space this is the activation of a set of actuator s aiming to fulfill the desire as previously mentioned The idea is that the user observes that state of the world. The user then classifies the state and interpretation function This classification gives rise to a set of contexts that are active, and each context is associated with a set of behaviors. The intention of these behaviors is to change the current state to a more desirable state. For example, i f user interprets the world as Cold I ndoor s, we turn on the heater with the intention to reach the desired context of Warm I ndoor s Definition 12 ( Desirability of Contexts ) A user forms opinion about the desirability of various contexts. We define the set of most desired contexts as D and the set of extremely u ndesirable impermissible contexts as X then the desirability, or the value function, of each context can be stated as: v:C {D, X,D X} where D, X C Definition 13 (User) A user can be denoted by a tuple B ::= Where T and I are the taxonomy accompanied by the interpretation of the user. The user can then specify D and X Let I: C S be a mapping from context to s tatements that shows possible intentions to transit ion away from a context c The discussion above assumes users to be always knowledgeable and rational, as the entire programming procedure hinges on the belief that user (or programmer) know the entire ta xonomy, can interpret sensed data properly and react to the contexts rationally. But realistically, this is not always the case, because people can be careless, ignorant, and they make mistakes


62 To build a well behaved and safe pervasive computing system, we need to define and evaluate the rationality of users (or the lack of). We consider a user rational if the desired goals identified are attainable, can make a clear distinction between the desired goals and the dangerous situation to avoid, and all inten tions and actions specified contribute to leading the universe towards the desired goals. Defini tion 14 ( Rationality of User ) A user b + =< T; I ; D, X, I > is rational if the following is satisfied: Attainable Goal : Function w i ( ) :C C describes the effects of i th time chain applications of intention I based on the active contexts starting from C 1 = I 1 = I 1 1 can lead the space from the currently active context R to the desired goal d d D, n I w n (R)= d Rational Goal: A goal is rational only if none of the desired contexts are considered to be dangerous impermissible contexts. D X = Logical Intention: Assume function evaluates the minimal cost to transition the space from context c to Then an illogical intention I can be expressed as: dist(R, d) < dist(w 1 (R), d), d D A suitable function for evaluating the cost of context transitions w ill be defined in the next section, when we present the evaluation of various options for the sequences of action to reach desired contexts D It is not unusual that there is more than one occupant within a smart space, and it is crucial that our model ha s to be able to accommodate multiple users, each with their own individual interpretations, desires and fears. A suitable composite representation of user must be defined when there is more than one user, and it has to be applicable to any situations where a single user representation can be used. Definition 15 (Composite Representation of Multiple Users ) Assume there are multiple users currently occupying the space, and each is represented as b i =< T; I i ; D i X i I i > If


63 there are misalignments between i nterpretations of contexts among users i and j then we define a temporary context as follows, i j The composite user representation can then be expressed as, b =< T; I ; D, X, I > where I (c) = I i (c) if c i i I I i (c i ) I j j ), c D = D i i X = X i i I(c) = I i (c) if c i i i (c i ) I j j ), c Notice that t he taxonomy T remains unchanged, as it provides common language and terminology for users and system alike to understand each other. The temporary context created due to different interpretations (and misalignment of these interpretations) between users would have to find common grounds between the inherited desirability and intentions from their original users. The desirability of these composite contexts can be described as follows, Definition 16 (Desirability of Composite Context). v(D) > v(D C) > v(C) > v(D X) > v(X C) > v(X) 5.1.5 Shaping the World as a Programm able Pervasive Space We can now define a space consisting of sensors and actuators and a user using the following operational semantics: Def inition 17 (Programmable Pervasive Sp ace) A programmable pervasive space can be denoted by a tuple consisting of: P ::= w here B + represen ts the rational user, R the currently active context, V the s ervices offered in the space and A is the set of available actuators. The preferred and impermissible states, denoted as D p and X p respectively, are space specific, based on its designated functions, social contexts and locale


64 A n example of how D p and X p can affect a programmable pervasive space is demonstrated by the drastic ally different preferred and allowable temperature and humidity in an engine room or operation room. By attaching different D p and X p to annotate attributes of these spaces, programs executing within the confine of these environments have to respect the re strictions and conditions and behave accordingly. Further examination of Definition 17 allows us to generate an even more detailed operational definition of what a programmable pervasive space is. A programmable pervasive space employs available services a nd devices to interact with the physical world based on the desirable goals and avoid undesirable conditions, within the limits allowed by the attributes of the space. Programming such a space requires developers to implement software artifacts that enable the services V The effective of the pervasive computing system depends on developers to properly implement the software to handle vast combinations of B + R V A D p and X p and continue to function properly despite the dynamic changes within the space. One last note, spaces change over time due to nature even without intervention by users or the system We model the effect of nature by a transition that chang es the state of the space, and observe the changes of the space through our sensors. Definition 18 (Environmental Effect) The environment effect e is what happens naturally or due to events beyond the control of the system. e: where f ( u f ( ) 5.2 Representation and Manifestation of the Fundamental Elements The four fundamental elements, device, service, user and space, can be specified in a pervasive computing system as follows.


65 5.2.1 Device Device description is used to explicitly capture or model semantic information, supported operation and method, domain value bounds (temperature, luminance, others), operation constraints (range, maximum usage frequency, enumeration of discrete values), physical medium description, interaction protocol, and others. By providing such device description information, the system would be able to operate and utilize the device while enhancing the device and overall system safety. An accurate and precise device description file of a devic e allows the system to understand how to interact with it which is crucial in handling highly diversified devices with greatly varied capabilities. The availability of this description allows a system to identify a particular device as a sensor, actuator or both Table 5 1 lists some useful and common attributes to be included in t he devices description file 5.2.3 Service Services in a pervasive computing system are more complicated than their counterpart executing in desktop or in client server architect ure, as the heterogeneity and dynamicity of smart space make proper management of changes in availability of critical resources a necessity which makes SOA or SOA like architectures a prevalent practice in pervasive computing. In a system that employs SOA device s are also represented as service s with additional characterizations and restrictions A service is one of a group of software artifacts with specific objectives. Services require necessary resources to accomplish these objectives, including device s (hardware) or other services (software). The functioning of these services often requires communications and interactions with other services in dynamic environments, which means the necessity of explicitly defining their dependencies and service interfa ces.


66 The business logic and lifecycle, in most of popular programming language today, are likely hidden behind objects or procedural calls, and the only information available is signature and public attributes. The advantage of this approach can be found i n discussions and books about programming languages. But in pervasive computing environments, it poses as both an advantage and a disadvantage, since dynamic compositions are common, and it allows any developer to plug in software artifacts as long as the interfaces are consistent, but makes no revelation or guarantee about the compatibility or correctness of the implementation. In most practical situations, it often relies on the implicit trust on the vendor or programmer to assume that the software artifa ct delivers the goals while avoiding the traps. A service in a pervasive computing system can be represented using the following three entities, interfaces, dependency description, and software artifact(s) that actually provide the expected service. Someti mes the interfaces or dependency may be embedded within the code, but with the SOA approach, it is preferable to make them explicit to facilitate the dynamic interactions. For example, the reference implementation of OSGi suggests explicit definition of in terfaces, places dependency related information in the manifest, and bundles them together with associated classes into a single bundle. 5.2.3 User A user in a pervasive computing environment is represented using a user profile, which should preferably be both human and machine readable. A complete user profile consists of two parts the static and dynamic profile. stable and usually not affected by the system. The preferences that are relevant to the services and do not frequently change over time, for instance, the information about special assistance required preferred room and water temperature, and


67 and contacts. The static profile helps the system to understand each user, hence en abl ing better and more personal services, or even anticipating specifically, they help to align services so services can deliver what users really ne ed and in ways that the y prefer. The dynamic profile, on the other hand, consists of the user related data gathered by the system and is continuously updated by the system. F or instance, the current location o f the user or the blood pressure and glucose level ob tained from medical sensors. The information in the dynamic profile is handled similar to context rather than static profile, which is mainl y used for setting up goals and preferences or identifying potential risks 5.2.4 Space A s pace in a pervasi ve computing system can be interpreted using the context manager and context gra ph, and is often associated with specific uses and social contexts. The state of a space can be captured using ontology based context graph, which not only tells the system ho w to interpret low level sensor readings into contexts, but can be used to monitor and visualize the currently active contexts. It all starts with the context manager continuously collects all available row sensor readings. These readings are fed to the as sociated context graph which defines how row data and contexts should be interpreted. I t also generates a comprehensive graph of active contexts, which provides an excellent visual aid in the form of snapshot s The context manager with the help from the context graph, is therefore capable to determine active contexts, and provides more abstract, refined context information to all the subscribing services and is in an excellent position to see the big picture and overall status of the space. Q uestions suc h as whether the room temperature is too high, whether the load in the circuit is acceptable or if the vitals of a house occupant are normal can be easily answered from this vantage point. Although the


68 capability of the context manager and context graph to interpret the entire space is limited by the availability of sensors and the construct of the context graph, together they represent a comprehensive model of the space among the sensible dimensions. The designed uses of the space with the social contexts depict the choices of desirable and impermissible contexts in the context diagram. The description of a space, along with the current state of the space, can be visually displayed using a context graph. The backend representation of the information shown i n the graph consists of ontology (standard or customized), rules of context interpretation and derivation, as well as the desirable and impermissible contexts based on the attributes of the space. Table 5 1 Attributes included in the device description f ile Type Sensor/Actuator/Both Domain of data e.g. Temperature, Luminance, Device Internal Data Schema XML Document Type Declaration Including, but not limited to maximum and minimum values, resolution of data, unit of data Interface Methods Methods available to be invoked externally Physical Medium Description Description of the Interface/ Conduit/Channel that is to be used Interaction Protocol Description Support for Poll or Push methods, maximum frequency of data exchange Other Support Inform ation e.g. Vendor and other contact/support information


69 CHAPTER 6 RISK ANALYSIS 6.1 Scenarios Jason came home after a long day at work. As he opens the front door and steps into the living room, he thinks of a simple meal and nice down time in front of TV. Instead, he sees the always regret the day he subscribed to the new energy saving service, ever since then the lamps would turn on and off by itself like a haun ted house. The technical support people told him there is a glitch when people subscribe to both lighting control and energy saving services, and they are still trying to work out a solution. Turns off the energy saving service, Jason walks into the kitche n to prepare the dinner. He takes a piece of steak out of the freezer and unwrap it. Jason places the steak in a pan on top of the stove, and scans the RFID tag on the wrapper next to the stove top control. The meal preparation service is the best thing th at has ever happened to a single guy, Jason ponders. The service automatically cooks following the recipe after identifying the ingredient based on the additional ingred ients, and automatically shutoff to prevent overcooking. Jason returns to the living room and turns on the TV to watch a ballgame. It i s the pungent charcoaly smell of something overcooked that get s his attention. He rushes to the kitchen only to see the juicy steak already turned into charcoal. Jason wonders how this could be, but soon find s the meal preparation service sets the target temperature inside the oven to 3500 instead of 350 as the oven basically becomes an incinerator. He did not even


70 know the stove can heat up to 3500 but he sure feels lucky that he was able to turn it off before any more damage is done. Distained, he throws the charred steak away and decides to reheat the leftover stew instead. Jason opens the fridge, picks up a bottle o f beer, and heads back to catch the rest of the game. Unfortunately, he does not close the door of the refrigerator properly and the cold air spills to the stove right next to it. To make sure the stew is well heated, the meal preparation service turns up the heat. To make sure the food inside the refrigerator are not spoiled, the compressor amps up the power. As the stew cannot be properly heated, and the fridge cannot sustain the required temperature, both the stove and the fridge push themselves to the l imit. Before long, both have been drawing so much power and a fuse is blown; and the entire house sinks into complete darkness. This is simply a nightmare, so Jason decides it is probably best to call it a night. Empty stomached, frustrated, and antagonize d about how the services he paid good money to subscribe to has turned his life into a sequence of unfortunate events, Jason twists and turns on the bed. When he wakes up, the alarm is blaring, the bed is shaking, and he feels as if a sledgehammer has punc hed through his skull. He feels weak and sick, and cannot get out of the bed. The morning call service, however, decides an extra push may be necessary to wake him up this morning. Struggling to climb out of the bed and trying to reach for the alarm contro l, by the time he finally turns it off, Jason feels like screaming and throwing up at the same time. soon fells asleep on the couch. The boiling soup spills over an d catches fire. The meal preparation service sticks to the plan and continue boiling the soup for a good ten minutes, while the fire quickly spreads. Wakes up by the shrieking fire alarm, Jason exerts and uses the


71 remaining strength to operate the fire ext inguisher. The fire has barely been put out before Jason after wake up from the long nap, the first thing to do is to completely remove every single smart thing i n the house. 6.2 Risk Analysis Before we can construct mechanisms to protect pervasive computing system s, we have to perform risk analysis By identifying potential threats, we are able to better understand the problem and devise effective preventive mo nitoring and protective mechanisms. Similar analyses have been established as a standard practice in research on computer and network security 92 and software safety 3 T he scenario presented above reveals how safety risks may occur, a s well as the root caus es and conditions that manifest them. We are able to identif y a number of distinct risks as listed in Table 6 1, b ut just like any security threat analyses, th is is by no mean an exhaustive list. To help understand the range of risk factors and formula te s trategies in dealing with them, these safety risks are categorized and presented in detail as follows. 6.2.1 Risks Associated with a Sing le Hardware or Software Component Component not fail safe ( h ardware and s oftware) Employing c omponent s that ar e not fail safe either hardware or software, in pervasive computing system is o ne of the most straightforward yet frequent safety hazard A component is not fail safe if: 1. It is not capable of detecting or understanding its own failure. For instance, a m otor can overheat and catch fire but the system is unaware of the situation because there is no self sensing or feedback capability.


72 2. It is not capable of proper handling or safely shutdown should failure strike. A related example would be the same motor re porting back the hazardous situation, but there is no emergency break to stop the motor or cut the power. 3. It does not provide adequate interfaces or self regulatory mechanisms to prevent improper operations from happening in the first place. For instance, a motor that can operate up to 10,000 rpm should not be allowed to receive instructions to ramp up past 15,000 rpm by the system. Every component has its own supported operations and the designated conditions under which they are to be performed Improper operations and errors made by h uman operator s usually are the result of carelessness, ignorance or misunderstanding. A well designed device will prevent inappropriate operations from taking place, and often embed hints and cues to minimize the occurrence of human errors. For instance, an oven should have proper temperature marks on the dial to inform users the range of its operation, and reject instructions to operate outside of this range However, when controlled by computers, these cues, hints and visua l feedbacks would often fall to deaf ears, resulting in more frequent errors and worse damag es Without proper assistance and restraints, p rogrammers who are usually offsite, become more detached from the devices hence ignoring the visual cues and physic al feedback s that might have signaled a mistake. The software that controls devices can also receive unreasonable commands because of an error as simple as a typo. The incineration of the steak is the result of an erroneously added 0 in the cooking instruc tion. Overextended resource Typical device used in pervasive computing systems possesses limited resource in terms of computation and communication power, as well as energy source. M ost of them are highly distributed meaning t he resource providers and requesters often locate on different devices connected by a network. More often than not, t here is no resource management or arbitration


73 system that can oversee the system wide resource allocation as the ones available in a traditional operating syste m. Shortage in resource itself seldom cause safety hazard if services and applications are implemented properly. The indirect impact of the shortage, though, can have significant implication on the system safety. Unmanaged resource allocation can cause thr ashing, starving and even deadlock, which all pose as potential risk factors. If certain software artifact monopolizes the scarce resources, it may hinder the capability for other services to perform critical or protective tasks. 6.2.2 Risks Associated wit h Component Interaction s and the Co existing of Components 6.2. 2 .1 Shared resource related safety risks Shared resources remain one of the most frequent sources of risks. Without operating system like management and arbitration mechanisms, the more ad hoc, dynamic pervasive computing system needs to ensure when services and applications share resources, the outcome should be deterministic, and there will not be deadlock. Either condition would reduce the predictability of the system behavior, and cause safe ty hazards. Due to the need to dynamically compose and adjust, service or activity based architectures have been widely adopted by pervasive computing systems. With these architectures, each individual service or activity focuses on accomplishing its own p redefined goals. While it is effective in handling the dynamicity heterogeneity and complexity of the environment, compatibility issue s between services d o arise, e specially when software components depend on one another, interact, or compete and race for shared resources. In a traditional computing system such as PC or server the operating system monitor s the use of shared resources and keep s track of the dependency. In pervasive computing systems, the lack of reliable monitoring


74 and arbitration mechanis m to oversee the large number of shared heterogeneous resources presents a major problem. 1. Contradictory usage of shared resource: Since multiple services or activities can be executing simultaneously yet each has its own agenda, without proper management or arbitration, contradictory instructions can be issued to the same resource at the same time or within a short time span. Depending on the design of the system, the shared resource can flip at high frequency, block and starve one, many or all requesting services, or bring the entire system to a halt. Any of these results could drastically reduce the efficiency and effectiveness, terminate the service, damage the hardware, or shutdown the system, which poses serious safety risks to the users and the system The flickering lights exemplify this issue when energy saving and lighting services each coordination, the lamp flickers when receiving conflicting directives from two ser vices. 2. Deadlock and livelock: They occur when ill regulated requests for share resources arrived at the same time, and prevent applications to acquire shared resou rces needed to complete tasks. As competing entities request for additional resources while holding on to ones required by other s none will be able to move forward and accomplish anything useful. Although it does not usually cause damage to hardware, they can cause suspension of services, as well as halting and unresponsiveness of the system. 6 .2. 2 .2 Race condition Just like any concurrent systems, if not implemented appropriately simultaneously executing software artifacts can interrupt and mingle with each other, leaving the outcome unpredictable. Nondeterministic behaviors can prevent applic ations from performing their designated functionalities properly and may cause unexpected damages 6.2. 2 .3 Conflicting goals The goals of each application within the system may not always be aligned. Unlike traditional computing systems, pervasive computi ng provide s services by interacting with and manipulating the overall state of a space. It is not infrequent for applications to exert influences on different device s and try to maneuver the space towards conflicting directions either knowingly or unknowi ngly.


75 Using the notation defined in the formal model presented in Chapter 4, this conflict in a context aware system can be described by g i ( u ) g j ( u ) = where a i and a j are two actuators in conflict and u a context In other words, if t he invocation of a i leads to a state of the world that is disjoint from the state to which the invocation of a j will lead, this state of the world can never arise. This situation not only wastes the resource and energy, stalls the progress towards the goal, but may also cause flip flop commands to shared resources, or unintentional side effects such as overloading of breaker. For instance, when a system administrator who is feeling unwell enters the machine room, the machine room climate control application wants to keep the room temperature low to prevent equipments from overheating, while the personal health care application wants to raise the room temperature so the person would not suffer further ailment due to low room temperature. A classical example of the invocati on of two conflict ing actuators is the air conditioning and the heater. A heater will raise the room temperature whereas an air conditioner will lower the temperature hence a statement that activates both the air conditioner and the heater at the same tim e is considered to be contradictory Each application may not know the existence of the other, yet the air conditioner unit would receive conflicting instructions that cannot both be accommodated. 6.2. 2 .4 Lack of scalability and inability to add c omponent s Dynamicity demands competent and efficient handling of component and service additions. The system has to be able to verify if components to be add ed are compatible with existing system, if the system is scalable enough to support more additions, or if th e additions can be proactively and effectively integrated with existing components Additional components can require more than affordable memory to cause thrashing; they can horde bandwidth for data


76 streaming and block out important message exchanges; the y can overwhelm the brokerage mechanism or data store to degrade or crash the existing systems. It is crucial to be able to evaluate and hold off those which may cause instability to the entire system. 6.2. 2 .5 Inability to adapt or substitute services prop erly Since most pervasive computing systems operate in dynamic and open environments, the requirement for software reliability and fail safe is high. When the environment chang es and existing services become unavailable, the system should be able to contin ue functioning by adapting and perhaps locating replacements for the missing components. At the very least, the performance of the system should degrade gracefully instead of simply crash and burn Service adaptation remains a hot research topic in pervasi ve computing, because there is no consensus yet regarding how to unambiguously specify service components, which is utmost critical in successful adaptation and substitution. 6.2. 2 .6 Conflicting side effects Side effects refer to the unintentional impacts occurred during the service provisioning or function performance. F or example turning on an incandescent light bulb has the intended effect of bri ghten a space, but it may not be immediately obvious that it also creates heat as a side effect. Some side e ffects are intuitive and predictable, while many others are not. Even when there is no shared resource involved the side effects can still cause conflicts between independent services. While i t is tedious and costly for each service to specify the appropr iate resolution when contention for shared resources occurs, it is nearly im possible to account for all possible interference s which can be caused by side effects. The unintentional side effects are rather limited in traditional computing, but can be a maj or source of risks in intell igent environments. The conflict between the fridge and stove in achieving their respective


77 predefined goals exemplifies this issue. Because side effects are often not explicitly stated or even i ll understood, it is difficult to establish effective preventive measures. 6.2. 3 Risks Associated with Space 6.2. 3 .1 Violation of space specific attributes Each space has its own designated use, social contexts and locale, and they usually translate into different restrictions and interpr etations of 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. Violation to the social con texts and attributes are usually more inconvenient and inappropriate than harmful, but risks can spawn depending on the situations. The high heat, humidity and non sterile environment that are common in an engine room can prove to be deadly in operation ro oms of a hospital. 6.2. 3 .2 Vague definition and inadequate monitoring of impermissible contexts Traditionally, developers are trained to focus on the goals and tasks of programs to be implemented, and how to devise the most effective and efficient algorith ms, data structures and execution conditions to achieve these goals and tasks. As the popularity of the programming languages with better exception handling mechanisms grow, the majority of commercial grade systems now include capturing and handling with e xceptions associated with programming constructs as well as designated events related to the tasks. For pervasive computing systems, we need to take a slightly expansive approach. In addition to construct level and task level exceptions, which are the dir ect results of the implementation, it is crucial to look at the system and the environment as a whole. In computing systems that strive to intertwine and be integrated with the physical environment, common sense prevail. Existent typical danger which is present even


78 before the introduction of these systems, such as fire, intrusion, and flood, are still considered situatio ns, such as dusty room for asthma sufferer or closed space for people with clausophobia, should also be considered as safety risks; the situations where resource usage or component interactions adversely affect the capability of a system to fulfill its des ignated tasks are also safety risks. Regardless of how a particular pervasive computing system is constructed, these dangerous situations, also known as impermissible contexts, should be clearly defined and diligently monitored. Failing to do so can sever users, properties and the system itself in grave danger. 6.2. 3 .3 Events caused by u ncontrollable factors Risks in an intelligent environment can arise because of system malfunction or user mistak es, but it is equally possible that bad things just happen. Just like any regular house, office or car, risks in these intelligent environments can be a direct result of events beyond our control, and the introduction of pervasive computing technology does not change this fact. Buildings could be struck by tornado, vehicles can be hit by other drivers, and blackouts can be caused by some mistakes along the transmission grid hundreds of miles away. These uncontrollable factors come in various roots and shape s. There might be natural disasters, human mistakes outside of the system, or simply a wide scale system failure. Obviously, devising mechanisms to deflect these uncontrollable risks and guarantee the safety is not a reasonable goal. Pervasive computing s ystems or their safety mechanisms are not designed to make tornados and lightning go away, or enforce responsible behaviors of every driver on the road. What these systems can do though, is to constantly monitor and handle these risks the best way it could They can monitor emergency warning on tornados, warn the users


79 and perhaps close all doors and windows to reduce the impact. They can analyze the driving behaviors of neighboring cars on the highway, and give warning about unsafe drivers. With collision prediction mechanisms, smart cars can even warn and apply break on behalf of users to minimize impact. 6.2. 4 Risks Associated with User 6.2. 4 .1 Violation of user centric computing Pervasive computing systems are intimate and personal, therefore they have to be user centric. While accessibility is traditionally an afterthought or an add on convenience when designing personal computing systems, it is a consideration that is front and center for intelligent environments. Many systems are specifically designe d to provide assistance to elderly, children or people with special needs. The use of voice commands, push button operations on devices and appliances, and audio/visual reminder and memory assistance have to be carefully evaluated from the onset and employ of users, user centric computing is no longer simply a wish or feature, but becomes the core of such a system. The del Context awareness is central to most pervasive computing systems. Context s reflect the condition of surrounding environment a what they want to achieve and avoid, and the preferred actions and services they believe can help achieving goals and avoiding hazards. Dealing with user related contexts often involves proper interpretations or even predictions Our experience indicates that even human cannot always read each other


80 correctly, let alone asking a computing system to do it. The misinterpretations, however, may cause serious harm and injury, such as the case when morning call service does not properly 6.2. 4 .2 Irrationality of users Users are not always rational. Throughout the design process of most systems, however, it is often assumed that they are. In traditional software engineering process, the irrationality of end users can be identified and eliminated through the proper knowledge engineering and r equirement specification process; and the irrationality and mistakes of the developer are handled with appropriate testing and verification procedures. For pervasive computing systems, which are more complex, dynamic and user centric than most, these est ablished processes may not be adequate. A more explicit examination to reaffirm harm than good. In particular, it is critical that the specified goals are rati onal and attainable, and the steps taken to achieve these goals are logical. A rational user should know what she or he desires and loathes, and the system can only assist if these states of desire and avoidance are specified in an unequivocal way. The spe cified goals should also be attainable, so system can identify the path leading to desired goal states and take actions accordingly. Unattainable goals waste valuable system resources and can prevent useful and achievable tasks from being delivered. A logi cal action should always lead towards desirable goals, and any that fails to do so would not benefit the space or the user at all. 6.2. 4 .3 Unintentional d isruptive u ser actions User is one of the three entities that can affect the environment and the syst em. They can alter the status of the environment through interactions and issuing commands with pervasive computing systems that monitor and control the space, or they can directly apply changes


81 through their behaviors and actions within the space. Disrupt ive user actions usually are the result of carelessness, ignorance or misunderstanding. People make mistakes, accidents happen, When under the stress of handling dange rous situation, they may panic and behaves irrationally. 6.2. 5 Misunderstanding about the System Dynamic compositions and adjustments is popular with pervasive computing s ystems 21,87 88 and clear and unambiguous descriptions on properties and protocols o f each entity in the system is the key to such proposition. Embedding the relevant knowledge about devices to use, the goals to achieve or the current state of the space in code segments without properly and explicitly specifying them fosters opportunities of misuse and conflicting hidden assumptions. 6.3 Observations and Characteristics of Safety Risks in Pervasive Computing The identified safety risks focus on no n malicious safety hazards, meaning they are caused by the system flaws due to improper desig n or implementation by user mistakes or careless actions, or by natural disturbance s beyond the control of the system This distinction does not that there exist potential attacks which are well orchestrated and highly complicated, and are devised after careful study of the architectural and behavioral patterns and weakness of a pervasive computing system. This study does not focus on the chess game of attack s and counter attacks, but instead concentrate on mechanisms that can enhance the safety of systems in general, when there is no intentional threat attempting to sabotage the system or harm the users. Although the risks identified are categorize based on t heir association with each element, the reality is, different risks are not always independent. For instance, conflicting goals and scalability issues can cause overextended resources, and vague definition of impermissible


82 context can be a symptom that use r centric computing has not been followed through. This is a fact that should be considered when devising the safety mechanisms. We can observe that there is no specific category for risks associated with device or service. When employing service oriented architecture, devices can be easily represented as services, and there is little distinction except devices have additional constraints imposed by the limitation of hardware. Most of the risks identified in the first two category apply equally well to both elements. Different kind of safety risks can be identified at different stage in the lifecycle of a computing system. Some can be identified and prevented at design and implementation stage, or before software artifacts are activated to become part of th e integral system; while others can only be detected and handled at runtime. On one hand, employing components that do not fail safely, or system design that can lead to race condition, conflicting goals or scalability issues can often be determined offlin e; on the other, resource contention, disruptive user actions or natural disaster can only occur once the system is activated. Similar to other well studied software issues such as binding and parallelism, how and where to implement and enforce safety pres ents an intriguing tradeoff between flexibility and efficiency. But unlike other existing issues, since some risks can only arise during runtime, both static as well as dynamic detections and handling must be employed. Compile time support is effective at defining exce ption handling routines, enforcing event driv en program model, prioritizing operations and alignments, or specifying impermissible contexts. Runtime mechanism is more effective in detecting the risks resulting from dynamic interactions and exc eptions arose during operations.


83 S afety issues in pervasive computing are broad and comple x therefore a collaborative effort between the middleware at run time and the programming aid at implementation time is necessary The middleware handles the enforcem ent of safety principles and dynamic behaviors, while the programming tool ensures the target systems support safety API and eliminates statically determinable unsafe operations. Table 6 1 Safety risks associated with pervasive computing systems Risks Ass ociated with a Single Component Component not fail safe Overextended resource Risks Associated with Component Interaction s and System Architecture Shared resource related safety risks Contradictory usage of shared resource Deadlock and livelock Race condition Conflicting goals Unscalability and inability to add c omponent s Inability to adapt or substitute services properly Conflicting side effects Risks Associated with Space Violation of space specific attributes Vague definition and inad equate monitoring of impermissible contexts Events caused by u ncontrollable factors Ris ks Associated with User Violation of user centric computing Irrationality of users Disruptive u ser actions Misunderstanding about the System Misuse and confl icting implicit assumptions


84 CHAPTER 7 DESIGN OF SAFETY MEC HANISM S 7.1 Existing Physical, System and Network Safety Mechanisms Applicable to Pervasive Computing How do we make an intelligent environment safer? Safety is not a new concept, and many exis ting mechanisms are applicable to pervasive computing systems. 1. Implementing fail safe physical safety mechanisms in addition to electric or software safety i s a prudent design decision. 2. Most of the safety mechanisms for computer systems and networks such as authentication, capabilities and security protocols can be applied with little or minor modifications. 3. Since failure is the norm in pervasive computing, any mechanisms that enhance the robustness and availability to allow systems work through fa ilures can enhance the safety of the overall system. It is a wise decision to leave the original physical device or interfaces in place as a backup For instance, to make sure the elderly is safe when the fall detectio n service fails to detect an emergency, it is better if the residents still carry an emergency button. To en sure the escape route is open when a fire disrupts the network or power line for the automatic door control, the regular door knob should be kept in place so people can always open the door Using t he physical device as backup in cost effective as these mechanisms are often already in place in regular environments. The reliability is also greatly increase d because they seldom fail Typical safety mea sure s for computers and networks, such as authentication, capabilities, security and privacy have all been well studied and plenty of mechanisms have been widely adopted Applying t hese techniques to pervasive computing systems usually require little or mi nor changes. Because of the number of devices in a typical intelligent environment, and many of them are low end sensors, failure is considered the norm during operations. Mechanisms


85 allow dynamic brokerage 21 failure compensation using virtual sensor and service re planning 87 88 to improve the availability of services all contribute to the safety of the system. O ur research effort focuses on the safety mechanisms that are specific to pervasive computing systems. T he potential higher penalties associated wi th the risks justify designing implementation time and run time mechanisms to enhance the safety of p ervasive computing systems 7.2 Safety Mechanisms Tailored Specifically for Pervasive Computing S ystems Pervasive computing systems have many unique chara cteristics, and operated in environments that are substantially different from most other systems. The various safety mechanisms described in the previous section, designed for systems preceding the days of pervasive computing, can definitely be employed t o enhance the safety. However, as pervasive computing systems face unique challenges discussed in Chapter 2 safety mechanisms specifically tailored to overcall these obstacles have to be devised. Since all systems are composed of the same four fundamenta l elements or a subset of them any potential risks would involve at least one of them. The design of the safety mechanisms follow s the strategy of first securing each element, and then reducing risks occurred during their interactions. Finally, to save s pace the all encompassing element, we devise the safety mechanisms for space as a safety net to capture any safety risks beyond the control of the system or anything that falls through the crack. In a typical computing system, such as desktop or server, t he operating system provides the mechanism of interrupt and exception handling vector. The mechanism safeguards the important shared resources such as memory, storage or I/O devices, and monitors and warns about illegal use and usage of resources, such as division by zero, access protected memory, or concurrent access conflicts. This time proven mechanism is very effective in handling unsafe operations and


86 resource conflicts. There is no equivalent support for most pervasive computing systems. Considering t he complexity of the target systems in intelligent environments, it is highly desirable to incorporate an effective mechanism that provides similar safety measures capable of monitoring and detecting conflicts on shared resources as well as illegal accesse s and operations. The safety mechanisms for each of the fundamental elements in pervasive computing systems are presented as follows, 7.2.1 Device Devices can become the source of risks when they receive improper instructions or operate outside of normal o perational range. Each device has its own designed operation range, which can be continuous or discrete. Any command that operates on a device outside of this range is potentially damaging. There are many known approaches to address similar issues, such as saturation, reset, or calling exception handling procedure. Specifying the steps to handle such occurrences in an exception handling procedure could accommodate the most flexibility. Safe power down sequence in the form of an event handler should be manda te for each device in the system. Similar to the hand break in a car, users know that there exists a break for any device when the current operating condition is dangerous. Each device needs to be accompanied by an event handler that can take over when the emergency button is pressed, and know how to power down the device properly and safely. This power down sequence can be triggered either automatically or explicitly by users. By specifying the maximum frequency allowed for alternating commands, we can al so monitor and detect if a service is ill programmed or multiple services with contradictory directives are competing. In either case, we can either call for the specific exception handling procedure, or simply power down the device then notify the users. The example of flickering lamps in the scenario can be resolved with this solution.


87 The inclusion of power down, out of range, and contradictory command exception handling procedures should be implemented and verified during programming time. The normal ra nge of operation, which should come with the XML description of the device, can be validated at compilation time if the device supports certain standardized API. For those devices which do not implement such API, the out of range operation will have to be monitored and captured at runtime, just as all cases involving contradicting directives. By providing such device description information, the middleware should be able to operate and utilize the device while enhancing the device and overall system safety. 7.2.2 Service In the dynamic environment of pervasive computing, a service is the smallest and simplest entity that can be well regulated. Services can introduce risks when they violate rules on sharing resources, engage in race conditions or deadlock, or own conflicting objectives from other services. The lifecycle of services can be appropriately modeled as a state machine and their interactions can be described by interfaces. The key to ensure that services operate safely is to carefully manage their li fecycles. We want to make sure services are always properly binded and aligned to perform to the service can always be parked at a relatively safe mode without caus ing additional damages to users, devices or itself. The lifecycle of services can be appropriately modeled as a state machine and their interactions can be described by interfaces. A complete and sophisticated service lifecycle management is one the core c apabilities necessary for any successful programming model for pervasive computing systems. Adoption of event driven programming paradigm can allow the


88 system to gain a clean control over services, and help programmers identify the appropriate actions unde r different states during the entire lifecycle of a service. Event driven paradigm breaks down the complication caused by intertwining binding, aligning and executing processes into lists of clean cut procedures applicable to different states, and enables management of each service using a simple, precise yet flexible state machine. It also enables asynchronous operating, which is favorable for a dynamic and failure prone environment such as pervasive computing systems. Because of the highly collaborative nature of services in pervasive computing systems, and the extensive personalized interactions with its users, a service instantiated fresh out of a compiler is not yet ready for action. In the dynamic setting typical in intelligent environment, devices an d the associated services can easily enters and leaves the space, they could also be modified or even failed. Each service has a list of critical services and devices that it depended upon for its successful execution. Before a service can be launched, it always first makes sure these critical services and devices exist and are active, and then proceed to properly binded Once the service in binded state, it has acquired access to all resources necessary to function successfully, the next step would be to setup the goals and targets. Unlike software in desktop or mainframe environments, the functionalities these services provided are usually much user profiles c be customized accordingly. Once the targets are set and service aligned the service will then be ready to serve its intended user. The logging facility provided in each pla tform that the services execute on provides the capability to real time monitoring and tracing as well as post operation analysis and debugging.


89 7.2.3 User Users are the most important assets any system should protect. Unfortunately, they are also the mos t unpredictable and probably the most hazardous of all, as more dangers are caused by the carelessness, ignorance or misunderstanding of users than any other problems in the system. Although there is little pervasive computing systems can do to prevent us ers from doing with the limitations and intentions of users can also impr ove the overall safety. The safety mechanisms to protect users should adhere to the following goals: Always be aware of the status and situation of its users, should there be any indication of danger or harm, appropriate actions or communications should be initiated to help users. limitations and loss profile, unless parts of the profile are harmful to themselves or the entire system, including the space, other users and properties associated with the system. To achieve these goals, we rely on the following safety measures. The dynamic user profile biometrics data including blood pressu situation including location, recent activity history, and carried items, can be gathered with sensors in the intelligent environment. The intelligence can be provided to services so they can ma ke decisions and take actions accordingly, in addition, it can also be fed into context manager and security monitor to trigger emergency routines should any undesirable contexts occur. ic section of user profiles. With every service aligned using these specifications in the static section before ready, malicious, ignorant, or unwell to align servic es in a way that may cause harm to him himself or


90 others. By identifying reasonable operating conditions of services, we can prevent these malformed configurations being employed during the alignment process. A priority based alignment process allows syste m administrators to lock out settings that are not supposed to be modified or customized by users, as do owners to restrict how visitors might alter their surroundings during the visit. 7.2.4 Space Whether a space itself should be considered as a fundament al element in the system is not always agreed upon. However, each space has its own restrictions and optimal settings based on its uses and social contexts. A space encompasses all other elements within, including the status of services, devices and users, and is critical for context awareness and accounting for side effects. When a pervasive computing system acquires raw readings from sensors and statuses of actuators, they are simultaneously fed to and interpreted by services, as well as the context graph and emergency detector. They can capture dangerous contexts and damaging activities occurred in the space that might be difficult to capture otherwise. The ontology based context graph provides visualization of relations between contexts applicable to the space. It also offers a simple graphical snapshot of the currently active contexts, which helps administrators and users to get an overall big picture in a single glance. The safety monitor, built on top of the context graph, is a safety mechanism. It mo nitors if the impermissible contexts specified by users or associated with the space have become active. Should such safety risk occurs, the system can take swift actions specified by programmers in an emergency handling routine, which can manipulate, cont rol and shutdown services and devices to eliminate the danger, prevent the situation from worsen, or at least send out warnings so appropriate people can take actions to intervene. Regardless of how the space arrives at the


91 situation where impermissible co ntexts become active, the safety monitor serves as the last line of defense to intervene and resolve the danger. 7.3 Design Considerations 7.3.1 Program Time versus Runtime Safety Measures Same as many features in computing systems, it is always critical t o decide where and when to insert the mechanisms to perform the target functions. Example includes compile time and runtime error checking, or early and late binding of variables. After the basic institutes of safety mechanisms are identified and devised, when to perform the safety checking functions presents an interesting tradeoff between efficiency and flexibility. On one hand, for many complicated and general purpose pervasive computing systems, especially when associated with intelligent environment, middleware is widely employed as the software architecture. The middleware can acts as a nexus of information flow in the system, whether they function as broker, common utilities or discovery mechanism, hence presents a great opportunity to intercept, exa mine and intervene with the data coming in and commands going out. On the other hand, the overall safety as well as the quality of the system can be greatly enhanced if we were to enforce certain safety features when the system is being developed. By devis ing proper API or taking one step further to create a programming tool that can guide and validate the necessary safety measures are in place, the system created would be able to execute anywhere and uphold a predefined level of safety practice. Since safe ty issues in pervasive computing are broad and complex, installing safety measures in middleware or programming tool alone will not be sufficient. Middleware is extremely helpful in detecting the risks resulting from dynamic interactions and exceptions aro se during the operations. With easy access to tap into the data coming in and out of the middleware, the overhead of enforcing safety is reasonable. However, with it comes to define the exception


92 handling routines, enforce event driven program structure, p rioritize the operations and alignments, or specifying impermissible contexts, the programming tool is far more effective. The safety mechanisms are therefore designed to be a collaborative effort between the middleware and the programming tool. The middl eware handles the enforcement of safety principles and dynamic behaviors, while the programming tool ensures the created code support safety API and restrict on unsafe operations that can detected statically. 7.3.2 Tradeoff between Safety and Power of Expr essions It is known that there is a tradeoff between expressiveness and safety of a programming language used in any computing system, which is also evident in pervasive computing. The more expressive a programming language is, the more power is granted to programmers. For instance, in language without strong type checking such as C, programmers can use all sort of smart tricks to store data into memory in a particular format, and later randomly casting it to any other data type at retrieval. While these ma neuvers can be useful for certain types of applications such as highly compact code for resource stricken embedded systems, the correct operation of the Without corresponding syntactic, semantic, and functional checking mechanisms, programmers can use an expressive programming language to create a wide range of systems with few limitations and little safety net. The consequences can be extremely dire in pervasive computing With all the challenges and difficulties in providing safety in pervasive computing systems as previously described, our goal is to devise a progra mming paradigm that allows programmers to utilize all the expressiveness at their finger tips, yet maintain and enhance the overall safety of the implemented systems by employing explicit and implicit embedded safety mechanisms that forms a fundamental par t of the programming model.


93 Figure 7 1 Tradeoff between safety and expressiveness of programming models in pervasive computing


94 CHAPTER 8 IMPLEMENTATION OF SA FETY MECHANISMS The implementation of safety mechanisms includes three major components, the static safety mechanisms, dynamic safety mechanisms, and the authoring tool. The static safety mecha nisms frame the structure of system implemented and mandate the provisioning of emergency procedures; the dynamic safety mechanisms target at runtime detection and handling of safety hazards, and is implemented as middleware modules on top of the existing Atlas Architecture; the authoring tool provides guidance to programmers at the implementation time to reduce potential safety problems of the system created Figure 8 1 summarizes the overall changes to Atlas Architecture after the introduction of these me chanisms. The most important objective we are trying to achieve with this implementation is to bring OS like rich system support, such as resource management, interrupt and conflict resolution, to loosely couple pervasive computing systems. In order to pro perly frame and position the implementation, we have made the following assumptions: Safety hazards of interest are those caused by the system, environment or users (non malicious) Systems based on the service oriented architecture (SOA) Availability of Pn P capabilities Programmers are capable and knowledgeable about the applications Design mainly for programmers, not end users Hardware support for emergency shutdown 8.1 Static S afety M echanism s To reduce the potential safety hazards, and encourage develope rs to follow safety aware programming process, we devised and implemented the static safety mechanisms for pervasive computing systems. These mechanisms provide compile time support that is effective at defining exce ption handling routines, enforcing event driv en program model, prioritizing operations and


95 alignments, or specifying impermissible contexts. The center piece of these static mechanisms is the prioritized safety API. 8.1.1 Prioritized Safety API The safety API, as shown in Figure 8 2 is an inte rface that should be implemented by the service objects. It forces developers to adopt event driven paradigm in the implementation, which fares much better in dynamic environments, and paves the way for the operation of the state machine for each service a t runtime. Also included is the onEmergencyPowerDown() method, which forces developers to provide this fail safe mechanism should the service or device fail. 8.1.2 State Machine and Service Safety Interface T o enhance control and tracking of services and p romote smooth operations in dynamic environment s typical for pervasive computing the event driven programming paradigm based on a state machine is adapted for all services ( Figure 8 3 ) There are a total of six states. init is the state when a service obj ect first instantiated; a service is binded when successfully acquired all dependent services; before execution a service needs to be aligned limitations; only then can a service start executing in exec state When emergency hit s, a service quickly move into emergency from any other state. Finally, a service which completes its objective or proceeds managed termination process ends up in the terminated state. A packaged utility known as Service S afety API manifest s the management of and transitions within the state machine, which waives programmers from having to worry about the proper operation of the state machine. The distributed, light weight, often less than reliable software artifacts in pervasive computing systems known as services make the adaptation of asynchronous, event driven programming paradigm a necessity. It enables the system overall to be non blocking, hence more


96 adaptive and fault resilient. The separation of service logic into corresponding states also prompts p rogrammers to focus on primary tasks of each state, such as internal resource allocation during init resource dependency management before becoming binded customization and personalization before aligned application logic in exec resource relinquishing and recycling in terminated and emergency handling if the service ever enters emergency state. 8.1.3 Mandatory Power Down Sequence onEmergencyPowerDown () method, part of the service safety interface, is mandatory for every service, in which programmers w ould describe the necessary steps, such as setting variable to a safe value (e.g. set the oven temperature to 0 before stopping the service), releasing any shared resource it currently holds, report power down status to service registry, and notifying se rvices it currently collaborates with, to ensure a service can be parked safely. This sequence is required to be reliable, atomic and follows a well defined protocol for termination in case of failures. 8.1.4 Preemptive Methods with Priority Methods are d esignated with one of the two priorities, high priority for emergency handling methods, and regular priority for all other methods. Regular priority methods should be implemented as preemptible using similar techniques as preemptive concurrent programming. 8.2 Dynamic Safety Mechanisms Certain safety risks associated with pervasive computing systems can only be detected and handled at runtime, such as those caused by dynamic interactions and exceptions during operations Figure 8 4 summarizes the dynamic s afety mechanisms supported by the middleware. The details of some of these mechanisms are given below


97 8.2.1 Device Safety Checker Each instruction issued to the devices needs to go through additional checking to ensure their conformance to the limitations of the target device, including the method invoked is supported, the operands are within the normal operational range, and the frequency of alternating instructions is acceptable. From the perspective of object oriented pr ogramming, it is preferred the ch ecking are performed within the device service object, but devices with small footprint or higher code reuse, they can also be outsourced to Device Safety Checker with device id and the parameters of instructions. 8.2.2 Context Manager and Emergency Detec tor Context manager uses context graph to interpret raw sensor readings into higher level contexts Contexts are effective ways to describe the overall status of everything in the space, including the users of the system. Active contexts are provided to se rvices for making context aware decisions. Emergency detector also check s these active contexts to see if any dangerous impermissible context ha s come true. Should any impermissible context be triggered, the emergency detector would invoke the handling rou tine in the emergency handler vector (EHV) using the associated emergency number. 8.2.3 Service Registry and Emergency Handler Vector (EHV) The service registry uses both volunta ry reporting and active probes to acquire the current state of each service, a s well as depe n dencies established during the binding process. It provide s the system an overview of all the services in the system which allows the system to handle the situation where the se rvice object behaves erratically or becomes irresponsive. In ei ther situation the middleware takes over and ejects the erroneous service object and gains control of the devices or services directly. This


98 represents a much more drastic action as compared to onEmergencyPowerDown() method. Registry also hosts EHV, the centralized knowledge base of emergency response routine s, which is conceptually similar to the interrupt vector in the operating system When each device and service first joins the system, it is mandatory to deposit eme r gency handlers into Registry/ EHV in case should any major problem arises; it also hosts handler associated with each impermissible context defined in the context graph. When an emer gency handler is activated, EHV issues preemptive high priority calls to suspend services, park devices, decouple dependencies or issue overrides to reverse the emergency situation. 8.2.4 User Manager Although not directly related to safety enhancement, th e forth piece of middleware module implemented in this study is the user manager. It hosts static and dynamic user profiles, which are digital representation of each user within the space. On one hand, s ervices make queries and updates to the user manager, and limitations. floo r or dangerously high blood pressure, be identified and treated as safety risks and handled as detector defines as an impermissible context and decides when to ste p in and trigger emergency handlers. 8.3 Safety oriented Service based Programming Model Unlike the traditional computing systems, which are composed of underlying operating system, which provides all the critical system services as well as an abstract in terfacing layer to access hardware, and various applications which depend on the operating system. Each


99 application is an autonomous entity that focuses on providing a specific set of functionalities, and more often than not, can be independently and optio nally installed or removed. On the other end of the spectrum, embedded systems often forego the services of an operating system, and focus on implementing ultra compact, highly efficient, and often single mission software due to the tight resource constrai nts. Such embedded systems are often designed and implemented by a single company for a well defined application scenario, which has total control over everything from hardware, software stack to its application. In pervasive computing systems, especially those in intelligent environments, hardware and software from a large number of vendors are involved, and new services can be composed or introduced on top of heterogeneous resources. Services need to discover and utilize these resources in a highly dynam ic environment. Since services are highly context preferences, limitations and activities have to become an integral part of the system implementation. The currently prevalent software architecture employed by pervasive systems is SOA. Enc apsulating small chunk of code with well defined interface that provides and fulfills a set of contracted services, SOA fares well in dynamic environments involving collaborative partners. Therefore, the implementa tion of SOA us ing pervasive computing syst ems includes the following components: 1. Services: Each service must follow a commonly agreed ontology and protocol to provide specific services. 2. User profiles: The facilitation of the context awareness and customization requires users to be explicitly model ed and profiled. Allowing the possibility of modifying and specifying the system behavior by users would offer an even greater flexibility.

PAGE 100

100 3. Space definition: Office buildings, hospitals, homes or cars, are examples of space, within which services and users exist under the same roof of an autonomous unit. The definition provides the boundary, interpretation and context to the system behavior. Who are the programmers implementing pervasive computing systems? The previous discussions already clearly indicate t hat the system is most likely not implemented by programmers from a single company. A close examination of these complex and dynamic systems reveals that there should be three different groups of people work in concert to implement and modify the system be havior: Service programmer: The most obvious of the three groups. Service programmers implement services that fulfill the contracted tasks and allow interoperable operations. For instance, hardware vendors should provide services for utilization and integr ation of the hardware into a system; service providers should implement value added services for purchase or subscription. Space programmer: Even when employing the most ad hoc and freestyle architecture, certain parameters and limitations are specific to each space. Much like the network or system administrators, the responsibility of space programmers is to capture and externalize these parameters, so the services operating in the space conform to these parameters. End user: It is often frown upon to list end activities in a quiet, integrated, and context aware manner. Until the day when a system can telepathically a simple as given explicit commands, manually change system configuration, or as elabora ted as scripting the system behavior or even write a new module to replace or enhance the existing ones. The spectrum for supporting end user programmability is wide and likely to be varied across different systems depending on the intended flexibility. O ne of the core principles of our proposed safety oriented programming model is to encourage explicitness in specification and utilization of knowledge. This explicitness allows generic system software to provided customized support pertaining to the partic ular configuration of a pervasive computing system. The provision of the generic services for safety

PAGE 101

101 ensure system safety, hence allowing them to focus on impl ementing the application logic specific to the services. The more flexible and powerful these generic safety services are, the of extensively implementing and c oding the safeguards. 8.3.1 Programming S ervices Services, including the specialized ones representing devices, are at the core of any pervasive computing systems. To externalize the knowledge associated with a service, service programmers should provide annotat ed metadata with each service implementation. The following is a list of different categories of most common information associated with services. a. Supported external methods and interfaces b. Generic information regarding the service c. Dependency d. Operational co ndition e. Binding requirement f. Alignment requirement g. Dynamic Information h. Other miscellaneous information pertaining to the service i. Service logic the actual code that implements and delivers the service. To the contrary of general belief, providing metadata is an important part of the implementation process, especially in dynamic environments or when employing SOA architecture. Service programmers who implement the code are also responsible for providing the information. Failure to provide metadata can result in services being rejected or sidelined by the system.

PAGE 102

102 The use of the information from various categories of metadata is rather diverse, and to include all of them in a single metadata file would be inefficient. In conforming to the general software engi neering practices for OSGi based systems, they are placed in the following files. 1. Implementation class 2. Interface class (specifying supported methods) 3. Manifest file (specifying generic software information, dependency, and pointers to the various descriptor s files of various purpose) 4. Service descriptor files (specifying the operational conditions, binding and alignment requirements) 5. Other descriptor files, such as specifications for visualization widgets, remote control interfaces. 6. Build file and other versi oning maintenance files (for service compilation and management) 8.3.2 Programming User Representations To facilitate the context awareness of the systems, and make sure they behave according to hin each profile, there are two parts, the static and dynamic portions. With each service, service programmers have to specify the related items in user profiles the ervices will have effects on. These have already been discussed and shown in the previous subsection, as part of the service descriptor file. End users, on the other hand, have to specify their own preferences, limitations and perceived impermissible conte xts, so the system can adjust and behave according to their intentions. The responsibility to provide emergency handler for each impermissible context lies with space programmers, however, end users should be able to choose, configure or adjust these emerg ency routines as they see fit.

PAGE 103

103 Ideally, user profiles are the digital representation of the person in the realm of intelligent as pendant or implantable tag), o r accessible from a secure backend profile server in the network are all effective for accessing user information. User profiles grow continuously as the person travels, the system expands, or new services and devices are introduced. Except the bare essent ial user information, the initial user profiles are slim hence users will not be required to fill out dozens of questionnaires before they can take advantage of pervasive computing systems. It is crucial to point out that the information collected in the u ser profile should all come from the direct or indirect input of the particular end user that the profile is associated with. Further discussion on the strategies of collecting, growing and compartmenting entries in user profiles is presented later in the Execution Model subsection. Users can also have their unique interpretation of the things surrounding them. The definition of coldness by a senior resident living in Florida may be quite comfortable for a live long Northerners. These perspectives and diff erent interpretations can be reflected in user specific context interpretation files. For a meticulous and controlling user, this file may include detailed definition of every single context in the ontology. For others, the context interpretation can fall back using the default interpretation associated with a space, with small number of overriding entries only on dimensions that they have strong opinions about. 8.3.3 Programming Space S pecifications The specification of space includes ontology based context defi nitions and the impermissible context specification pertaining to the particular space. It also includes context interpretation rules essential to the context acquisition and interpretation. Defining of these rules allows the system to interpret raw sensor readings into particular atomic contexts, and interpreting higher level abstract contexts from atomic contexts.

PAGE 104

104 Space programmers are responsible for defining these interpretations, identifying impermissible contexts, as well as the implementing actions t o be taken during the emergencies. The context interpretation file is necessary for the operation of the system, but is not necessary to be space specific. A generic ontology or a derived version of generic ontology can often serve equally well in defining a space. The specification of impermissible contexts associated with a particular space is highly encouraged, although also can be optional in general spaces without specific restrictions. If impermissible contexts are already defined in the generic ontol ogy, space programmers can define impermissible contexts with the one of following strategies: 1. Local impermissible contexts overriding the generic ones. 2. Intersection of local and generic impermissible contexts. 3. Union of local and generic impermiss ible contexts. 4. Programmer specified context by context specification. 8.4 Safety Protection at Runtime Working together, the static and dynamic safety mechanisms can enhance the safety of pervasive computing systems. The detailed inner working of the p roposed safety enhancement mechanisms during both the initialization and execution phases are described next 8.4.1 Initialization Initialization precedes the actual execution. For pervasive computing systems as complex as intelligent environments, a fair amount of setup and preparation is necessary to ensure the successful execution and deliverance of services to users. We examine this process associated with when the system first starts up, when new services or devices are introduced, and when a new user enters the space. 1. Space/System initialization: The space is managed by the system and an environment can only become intelligent after the system is up and running. The system core has to be properly initialized and started, as do the primary utility and management middleware and

PAGE 105

105 software. As far as the support for safety enhancement is concerned, there are three modules which need to be initialized. The safety services, such as the EHV and device safety checker mentioned in section 8.2, needs to be loade d and initialized. Ontology and context interpretation file(s) associated with the target space needs to be initialized. Each sensor and actuator, and certain software artifact such as virtual sensor 87 88,93 expands the ability of the system to better int erpret and interact with the environment in additional dimensions. The context awareness depends on the definition of the mapping between the raw signals, sensor readings and the atomic contexts, which can then be further composed into more abstract contex ts. The specification of impermissible contexts and the emergency handlers. Dangerous situations should be identified as impermissible contexts, and corresponding emergency handlers be implemented to resolve these safety risks. These three modules are all mandatory, and provide the foundation of the safety mechanisms in a pervasive computing system. The safe initialization and execution of services and protection of users rely on their proper initialization. I t should also be noted that once the space is in itialized and system is up and running, a working intelligent environment should remain working amid all the changes in services and actions of users Shutting down or reinitialize a space and its pervasi ve computing system should be a highly rare occurren ce. 2. Service initialization: As explained in the previous section, the complete implementation of a service includes more than just writing a few lines of code that implements the service, but also proper specification of metadata associated with each servi ce. The proper initialization of services includes verifying the provision of the crucial information, the conformance to the safety API, the specification of emergency handler, and the proper registration with the system. The details on these processes ar e described as follows, Validation of metadata : Manifest file contains essential information about a particular service, and links to other relevant metadata. A service description file contains very specific information crucial to the proper operations of the service, such as operation parameters, dependent resources and alignment information. The validity of many entries in both files can and should be validated during the initialization to make sure the legitimacy and the required system support of a ser vice. Verification of support for safety interface and emergency handler : To make sure a service can utilize the middleware support for safety enhancement as designed, it has to implement the prioritized safety API and follow certain scheme of event drive n operations. The system also has to make sure it knows how to handle and properly shutdown the service should emergency arises, in the form of an emergency handler. All new services introduced needs to deposit the emergency handler to EHV.

PAGE 106

106 Due to the larg e number of heterogeneous devices and services in a pervasive computing system, it is impossible to acquire sufficient knowledge to verify the effectiveness and correctness of the methods declared in every interface and the emergency handler. Our goal is t o standardize and provide the common procedures with minimal distraction to programmers, hence allowing them to implement the device or service specific emergency handling or other supported methods. It also ensures other methods has lower priority, and ca n be preempted should emergency arise. Registration with the system : In a dynamic environment such as pervasive computing systems, each service must somehow make its presence and capabilities know to the system and other services. As part of the initializa tion process, each new service must first register with registry, acquire a unique service instance id, and the proactively report its service status to the registry. For safety reasons, new services will not be allowed to interact with others or be used t o compose complex services, until EHV and service registry verify they are properly initialized. Once verified, these services can be integrated as part of the system and start offering useful services to users. 3. User initialization: Whenever a user enters a space, the system attempts to id the user and retrieves the associated information (profile). If no such profile exist (or failed to retrieve from the network), the system will initiate a new user profile containing only the entries that services in the system might need. For services requiring mandatory alignment (which is relatively rare), the system prompt users to acquire the necessary information; for services with preferable alignment, users can decide whether they would like to be asked before the services are initiated. Should the users choose to be involved, they will be asked every time service requiring new information has come to existence or is being accessed. The acquisition and creation of new entries in user profiles for services come into existence overall overhead. 8.4.2 Execution With all the preparations and setup of safety aware programming procedure and initialization, the bulk of actions i n providing safety protections to the users, properties and processes of pervasive computing systems occur during the execution phase. We next examine the safety mechanisms and their operations during the execution. 1. Service: The operation of each service f ollows a well defined sequence of stages. A service has to implemented, installed, initialized, and it has to acquire necessary resources and align

PAGE 107

107 users. During the execution, it may encounter exceptional situations, which can be either handled quietly without major disruption or in some cases completely halt the execution and requires damage control. The availability of a service to its users and other software h inges on its current state. When a service switches to emergency state, none of its services are available to other entities, as it has to follow the emergency shutdown procedure immediately to contain and reduce the potential damage. The transitions betwe en states are triggered by various events. When a required resource emerges or a binded resource becomes unavailable, an event is generated. When the status of user changes, or when a user changes her or his mind, an event is generated. When emergency situ ation or operational error arises, a different kind of event is triggered. At runtime, each service monitors the commands that it has received, should unsupported commands or invalid parameters be invoked, the control is relinquished to emergency handling routine (sometimes with predefined handling strategies). Each service also keeps a history of past commands received to analyze the frequency of commands received to avoid flip flopping or executing conflicting directives. To prevent the concurrent executi on and resource contention related issues, each service is assigned an id at the time of initialization, and resource binding has to follow the strictly ascending order of service ids. gated to report their statuses to the registry and maintain a log that can be reviewed and backtracked should the need arises. 2. User: (participating, intrusiveness) in the user p rofiles, they may be prompted to provide further information to assist the alignment of services. These newly acquired information (if any), and the dynamically collected user related contexts are keep in a temporary file (either in memory or permanent sto rage) to enhance When a user exist the space, or when the space shutdown, the information acquired from the thrown out unless the type of data is annotated as sticky. 3. Space: During the execution phase, which corresponds to the majority of a a space performs the following context monitoring tasks Subscribe to all sensor data streams and events Sort through the acquired data with context manager to acquire the higher level contexts. Process and h andle received events accordingly. Monitor impermissible contexts and emergency events.

PAGE 108

108 Take actions by employing the corresponding emergency handling routine in the EHV. In addition, the space/system also provides the following utility service s : Maintain the registry, which contain s information regarding services ; hand out unique id s; and record the current status of existing services Maintain the EHV which manage s all emergency handling routines to ensure appropriate actions can be applied during emergency. 8.5 The Effectiveness of P r oposed Safety Mechanisms Using the unsafe scenarios identified earlier, we now demonstrate how the proposed safety mec hanisms can effectively mitigate or eliminate various safety risks during both the initialization and execution phases. 8. 5.1 Scenarios When the service that represent the lamp receives interleaving contradictory instructions to turn on and off above the a cceptable frequency as specified in the device description, the device safety checker first determines if these instructions have different priorities. It would then filter and ignore the less critical one. If instructions are of equal priority, to avoid p otential safety hazards resulted from the high frequency flip flopping, the service is moved to emergency state, and emergency handler can safely takes the service offline. Similarly, services are moved to emergency state if an invalid instruction asking t he service representing the oven to operate at an unreasonable 3500 F. Once the device services are power down and taken offline, the higher level services that depend on them will have to either re compose themselves by substituting with alternative serv ices, or to follow suit and propagate the power down. In either case, the conflictions exerted on shared resources and invalid instructions will cease to have effects and potential risks averted. When cold air spill from the fridge, the interaction between the fridge and the stove cannot be easily foreseen, as it underscores the difficulty in proactively define and defend against all

PAGE 109

109 possible hazards resulting from combinatory side effects. The improperly closed door of the fridge ends up causing unsafe pow er draw and blown fuse. This type of hazards cannot be readily handled by device safety checker. Instead, the emergency detector works in tandem with context manager, constantly monitors the overall status of the space and users within it. Not proactively preventing the unsafe situation from emerging, and not associated with a specific service or a device, the emergency detector basically monitors and reacts when safety hazards occur. By defining the extreme power draws as impermissible context, and define an emergency handler to prevent any additional request for more power, and prioritize the existing power drawing services, the system can prevent catastrophic safety hazards from materializing and control the damages if occurred. Successful pervasive compu ting systems in intelligent environments have to be user centric. Many related projects strive for context awareness, which is crucial in many application domains, but from a slightly varied perspective, we argue that all services and the space as a whole have to focus on what are beneficial to users and respect their preferences and limitations. The explicit aligned state of services enforces this notion. By ensuring each service has to be ammers to place considerations regarding users in the center of the design and implementation process. For instance, if aligned contact family physician ins tead of making him sicker by rushing him out of bed. In this case, the aligned service detects an abnormal context of sickness, and retrieves the contact of physician from the EHV and initiates the communication. In case of resource hogging services, non p reemptible methods, or if service has simply become non responsive, the emergency detector will be able to get a handle on the service, look

PAGE 110

110 up the emergency handler in EHV, and kills the service. It will also perform follow up procedures to make sure the share resources are released, and the devices are placed in a safe setting. 8. 5 2 Discussion The mechanisms proposed above provide basic safety protection against abuse of device and service, ensure explicit user profile alignment is part of the implementa tion, and use impermissible contexts as the second line of defense against safety risks not explicitly tied to any particular service or device. They provide invaluable safety enhancements over current pervasive computing systems, but there is no guarantee of safety. Just like any existing products and systems that claim to be safe, such as a safe razor, the term is only used to describe that the product is safer than alternatives. These mechanisms also promote the safety aware design and implementation pro cess. It prompts programmers to think about and implement safe emergency power down sequence, the and limitations affect the operation of services. The bottom l ine is, the responsibility of creating safe systems still lies with the designers and programmers. They can implement an empty emergency method without any instructions, and they can create align method without actually lso not specify acceptable operation conditions of devices. They may even implement ineffective methods against safety hazards. Due to the heterogeneity of devices and services, and dynamicity of possible combinations, coupled with potential risks raising caused by users, system and the nature, there is really no way to ensure these methods are effective against potential safety risks. The proposed mechanisms provide effective safeguard against safety hazards, assuming the programmers diligently implement t he methods in the API with effective safe aware operations.

PAGE 111

111 L ike any other engineering disciplines, the proposed safety mechanisms are designed to protect against already identified safety risks, such as those shown in the scenarios. The difference is per vasive computing has only began to emerge in the last two decades, and lacks mass deployments in the real world environments, there are many potential safety risks still yet to be identified. One of items on our future work is to further explore other safe ty hazards and design mechanisms to counter them. Although most pervasive computing systems are general purpose, therefore making it unrealistic to devise safety protections against an exhaustive list of specific threats, the aforementioned mechanisms can actually provide rather effective protections against risks related to the device and space. We are currently looking into further protection on services regarding the risks associated with shared resources and system resource usage. 8. 6 Authoring Tool To guide and assist programmers through the development process of safe pervasive computing systems, a simple, easy to use basic development tool set is implemented as a plug in exten sion to enhance the capability of the popular open source integrated develop ment environment (IDE) Eclipse. It allows the application developers to browse and retrieve other services that are available, develop new services and applications or modify old ones remotely, and deploy them back. This authoring tool provides a step by step guidance to design of new service s enforce programmers to explicitly specify important semantic knowledge during the implementation process, and provides templates of source code that allow the developers to concentrating on implementing the logic fo r the service without worrying about the details of writing OSGi bundles or establishing safety mechanisms When combined with the design of the static safety API, we have successfully hidden almost all of the extra Java code required to write OSGi

PAGE 112

112 bundles so programmers can focus only on service logic if they are implementing a regular Java program. Static safety mechanisms are incorporated automatically into the system created using this IDE as part of the template provided to developers. A t the time whe n a new service is created, the priority safety API, including the onEmergencyPowerDown () method are included by default The software architecture for the services allows most common actions and safety procedures be provided automatically as part of the b ase classes (Figure 8 5) while d evelopers only need to fills in tho se service specific methods with the appropriate business logic. Before the IDE deploy a new or modified service to the target system, it verifies the service to be deployed has indeed imp lement ed this interface before fulfilling the deploy ment command The IDE also include s the bootstrap code to register and deposit the emergency handler prior to the activation of a service. Shield ing these integral safety functions from the developers, it ensures that dynamic safety mechanisms in the middleware would work smoothly with new ly created services, while placing minimal burden s and attention s on the service developers. Eclipse is an IDE originally designed for Java program ming. As it happens, OS Gi platform and the service bundles are also designed to be implemented in Java The decision to develop the IDE tool set as a n Eclipse plug in is therefore quite straightforward But there are more reasons for this design decision, Eclipse is implemented to be completed platform neutral, allowing develop ers to use Windows, Linux or any other operating systems which can run Java program s. Eclipse provides an open platform, allowing numerous third party plug ins to integrated seamlessly with Eclipse, hence a llowing its capability to be further enhanced as the synergy between the original functionalities a nd the installed plug in s continues to grow

PAGE 113

113 C hoosing to implement the IDE tool set on top of Eclipse makes it possible to take advantage of all the availab le extensive capabilities, to allow programmers to use an IDE they are probably quite familiar to start with, hence make the task of programming safe and less error prone OSGi service s much less daunting for programmers. Eclipse and Safe Service IDE tool s et should be setup on computers designated as the development environment, which can be either the same computer where OSGi framework is running or a separate remote machine. It is expected, however, in majority of practical deployments, the runtime envir onment would be closely associated with each smart space, and therefore be on a separate, remote machine from where the application programmers would be working from. The Safe Service IDE provides a convenient and efficient tool for developers to program c omplex systems remotely, which potentially can introduce dramatic improvements in

PAGE 114

114 interface serviceS afetyMechanism() { boolean onInstantiated(obj); boolean onBinded(obj); boolean onAligned(obj); boolean onExecutionReady(); boolean onEmergencyPowerDown(); boolean bind(obj[] devices); boolean align(obj[] userPref); boolean execute(obj); } Figure 8 1 Updated Atlas Architecture Figure 8 2 Priority Safety API Hard Park

PAGE 115

115 Figure 8 3 State diagram for services Figure 8 4 Dynamic safety mechanis ms in the middleware

PAGE 116

116 Figure 8 5 Software architecture of safe services

PAGE 117

117 CHAPTER 9 AN ALTERNATIVE: THE CONTEXT DRIVEN PROGRAMMING M ODEL So far, we have established a safety oriented programming model with safety API and middleware components to enhance safety measur es in pervasive computing systems. They are designed for the most popular system architecture based on services. With the service oriented architecture (SOA) or SOA like approach, the entire system is comprised of services. Each is a self sufficient entity that has predefined goals, dependent resources, and well defined interfaces. They interact with each other and more complicated services can be composed using simpler ones. Many existing programming models and middleware designs take similar approaches wi th variations that falls into this category 95 96 During the process of devising safety mechanisms for systems implemented using SOA or SOA like approaches, we aimed at internalizing these measures by taking the bottom up approach and integrating them into the basic elements within the systems. The inherent narrow and individual perspectives of these approaches, however, make these mechanisms appear as addendum of safety enforcer tagged afterthought instead of an integral part of system composition. The fre quent interactions and compositions of individual services make the proposed safety mechanisms appear clumsy at times and not reassuring enough if unexpected safety hazards can arise amid all these interactions, despite the use of context monitor and layer ed safety approach. Therefore, we set out to explore other alternatives, in hope of finding a programming model that can take a wider perspective and is capable of identify, limit and monitor safety risks in a more natural fashion.

PAGE 118

118 9.1 Context Driven Progr amming Model 9.1.1 Shortcomings of SOA and SOA like Programming Models The number and variety of services running in a typical pervasive space grows quickly as pervasive computing technology matures, which dictates that a programming model is required to i mplement and assemble them as software. The keystone of such a model is context because of their dynamic and heterogeneous nature, as demonstrated by the number of research project in support of context aware pervasive spaces 40,52,64,94 While these progr amming models provide a convenient means for specifying the rules and behaviors of the applications with a formulated and systematic process, they do not provide an easy way to grasp the overall state of the smart space with a glance. In these models, obta ining what to look for, explicitly query the system for particular data, and then compose and interpret the collected data, weaving them into a comprehensive und erstanding. As the number of applications grows, the scenarios become more complicated, and services from by different vendors are forced to collaborate, conflict is almost inevitable. It is not always straightforward to detect conflicts, because each ser vice focuses only on its own goals, and ignores potential side effects or concurrent access to shared resources side effects that could put the space into a dangerous or anomalous state. Furthermore, they lack a simple way to identify, at a global level, unsafe contexts that should be avoided and the means to escape if they arise. Instead, each service must have its own routines for detecting and handling these situations. This place an unrealistic burden on developers, and renders safety guarantees infea sible, as any single missing or erroneous handler can trap the system in one of these impermissible contexts.

PAGE 119

119 Most of the safety mechanisms and software practice proposed in this study aims at mitigating these issues. The introducing of safety API, mandato ry power down sequence and emergency handler vector promotes safety awareness and forces developers to stare at and consider safety risks during the design and implementation. Whether these routines are implemented faithfully and effectively is beyond the scope and becomes the weakest link in the effort to enhance safety. To shore up and strengthen the safety guarantee, we need to establish a model in which safety is more integral to the behavior of the systems. 9.1.2 Design of the Context Driven Programmin g Model Since existing models and tools are unsatisfactory in providing safety guarantees and conflict management capability, we began expanding the ideas of context oriented design to create a new programming model for pervasive spaces. The main idea is t o employ standard ontology to build a context grid that represents all possible states of interest in a smart space. Contexts in the graph are marked as desirable, transitional, or impermissible, and the goal is to take actions to lead the smart space towa rds desirable contexts while avoiding impermissible contexts. At runtime, the torrent of raw readings from sensors are interpreted and classified into active contexts, and the associated actions are set in motion to drive towards and strive to maintain wit hin the desirable contexts. sequence of actions taken based on continuously evolving active contexts. It is therefore very easy to prevent and to verify that no conflicting actions are associated with each context. Decisions on action plans based on the active contexts also avoid the danger that can be caused by executing interleaved actions from different services. The explicit designation of impermissible contexts allows t he system to take emergency actions and exit the dangerous situations. All of these contribute to the enhanced safety guarantees our model can offer.

PAGE 120

120 Finally, the explicit context graph and the visualization of currently active contexts allow real time, at a alike an understanding of the overall picture of the smart space. We conclude the discussion on the motivation in searching for an alternative programming model by presenting a comprehensive comparison of these two models in Table 9 1. 9.2 Modified Formal Model In order to construct an alternative context driven programming model, we first revisit how we interpret a pervasive computing system using the formal model established in Chapter 4. The effects and functions of sensors, actuators and users remain the same without any changes. However, since our goal is to establish a model based on context that defines the behavior and reactions of a system according to the currently act ive contexts, we need to adjust how we define a programmable pervasive space. Def (Programmable Pervasive Space using Context Driven Model ) A programmable pervasive space can be d enoted by a tuple consisting of P ::= Where B + is the representation of the rational user, R the currently active context, S the statements we are currently processing and 2 A the set of actuators currently active. The preferred and impermissible states, denoted as D p and X p respectively, are space specific, based on its designated functions, social contexts and locale V the set of services available is no longer a part of the defining elements of a programmable pervasive space. We have defined services earlier in De finition 11 which remains unchanged and is still valid for the context driven model. However, with the SOA, which is the chosen approach in Chapter 5 the instructions, including statement sequence (Definition 10), branching and looping are all specified within one or few concentrated software artifacts, which generate a more procedural view about how services are to be delivered. With the context driven model, as the name implies, a system is no longer

PAGE 121

121 comprised of services. The instructions and actions t o be performed are instead embedded with each context. The delivery of a service is therefore a concatenated sequence of actions based on the evolving currently active contexts. In other words, while the definition of services is still valid, it is no long er relevant, as the system composition is not defined by services any more. Instead, we define the act of programming a pervasive space as follows, Definition 19 (Programming a Pervasive Space). We can program a pervasive computing system to alter the sta te of the space using actuators available at its disposal The following transitions capture the turning on and off of actuators: Activation : Deactivation : If active context s have changed, we obtain the intentions from the user and execute the desired sequence of actions: Actions triggered by Context Change : whenever R ( R ( u ) Notice the state of the space can change with the dea ctivation of actuators as well as For instance, turning on a ventilation fan is an action that has an intentional effect of transiting the air quality in a house from Murky A ir to Clean Air on the stove to sear steak, on the other hand, can produce smoke and degrade air quality from Clean Air to Murky Air By turning off the stove we may eliminate the source of the smok e, a passive intention. In our model, the active intentions (what happens when an actu ator is turned on) are specified by programmers, and the passive inten tions (what happens wh en an actuator is turned off) are inferred by the system. 9.3 Programming Procedure The context driven programming model presents a different perspective that is based on context interpretation and how pervasive computing systems shou ld behave under various

PAGE 122

122 circumstances. It reacts to currently active contexts instead of proactively pursuing agendas and pushing services onto its users. Its ultimate goal is to take the system and space through series of context transitions and arrives at a desired context specified by the user. To substantiate the goals and the philosophy associated with this model, w e establish the following programming procedure: Identify domains and contexts of interest : Programmers have to identify the domains of in terest, and within each domain, the contexts of interest. This process is heavily influenced by availability of the sensors and actuators the services planned, and the users' belief and desires. Identify Desired and Impermissible Contexts: Programmers ne xt identify desired and impermissible contexts which belong to D and X. They can either specify an atomic context along a single domain, such as Warm or a derived context such as (Warm Clean ) that is derived from more than one domain. Specify Intended Behaviors : Programmers have to describe intended behaviors in terms of desirable context transitions with atomic contexts o n each domain so that smart space knows which direction to go w hen various contexts become active Notice these intended context transitions can only lead to neighboring contexts, for instance, it is not allowed to specify an intended transition from Dusty to Sterile directly, as they are not adjacent to each other. N otice the programmers can also specify intended behaviors for a derived context if they choose to, such as specifying the intention to always try to move from ( Dusty Cold) to ( Clean Warm ) But the adjacent neighboring rule still applies to each domain in the derived context. Each derived context inherits intentions as well as desired/impermissible status from its component contexts. When programmers directly specif y an intention or identify the desirability of a derived context, this more specific annotation overrides the inherited ones. At this point, programmers have completed the programming process. The pervasive computing system now takes over to construct the core of the system in the form of a high dimension context grid. In order to construct this grid, the system first creates indexes for atomic contexts in each domain. For instance, on the dimension D 1 (temperature), the context Cold Warm and Hot have

PAGE 123

123 bee n given index of 1, 2, and 3 respectively. For non discrete domains, these indexes are given in the order that is consistent with the contiguity in the range of values. These indexes are only indexes, and do not carry any extra meanings. Using indexed cont exts along each domain as an axis, the system can now constructs the high dimension context grid. For instance, for a system that covers three domains of temperature, air quality and power draw, the resulting context grid is a 3 dimensional cube. The small unit cube in Figure 8 4 represents the derived context of Warm Sterile HighPowerDraw The combinations of various contexts in different domains enumerate all possible derived contexts in a high dimension grid. Desired and impermissible contexts D and X i dentified by users can point to a single node, or defined in a linear expression that can be represented in the grid. The next step is to determine which actions and behaviors to adopt. We first examine the available information collected and formulated by the system. All possible contexts are laid out on the grid, where R D X can all be located and pinpointed. As shown in Figure 8 5, we know the currently active contexts are R and the goal of the system is to get the nodes marked as D while the system should strive to avoid X at any cost. All the system has to do is to find a route from R to D through adjacent nodes without entering X in essence, we have transform the service provision problem in context driven programming model into a high dimension p athfinding problem. This conversion allows the system, with proper formulation, to use existing pathfinding algorithms, such as A* search algorithm, to automatically find the best way to get to desired context D The currently active context R will serve a s the starting point. Since the contexts are

PAGE 124

124 only allowed to transition between neighboring states, we start by exploring the neighboring nodes of R in the context grid. A* uses a two part cost function, dist() = accumulated() + est_dist_to_go() accumulate d() is the accumulated cost of getting to current position from the starting point, and est_ dist_to_go() is the estimated cost from current position to the goal. The objective of A* is of course to find the route with least cost to go from the starting poi nt to the goal. Since there is already an established context grid with coordinates, we want the cost function to include the movement in every single coordinate. It is also preferred to stay with the same actuator that can continue to move the space towar ds the desired context without having to constantly activate/deactivate various actuators. The impermissible contexts are to be avoided in with neighboring context s which cannot be transitioned in one step with a single statement. There might be more than one actuator that can take the space from one context to a neighboring context, as the space heater and air purifier shown in Figure 8 2. Each will be evaluated a s a separate route. For actuators that have effects on more than one domains, the system assume turning them on will have affects on all the associated domains. For instance, turning on a light bulb will heat up, brighten and increase power draw of the spa ce at the same time. The following definitions for accumulated() and est_dist_to_goal() can be used to find the optimal action plan to the desired context. Definition 20 (Cost Functions for A* Algorithm) Assuming the original active context is r the pote ntial active contexts along the route of action as u and with as the resulting next active context after action is taken at u and the desired context as d It is also assumed there are a total of N domains under consideration, and the cost function s are defined as, Overall cost estimate:

PAGE 125

125 dist( u, d ) = accumulated(r, u ) + est_dist_to_goal( u, d ) d D Accumulated cost: | i i (u)), i [1, N] | + 0.5 *( count(activation(A)) + count(deactiv ation(A))) Estimated cost to goal: Est_dist_to_goal(u, d) = i (u), coord i (d)), i [1, N]| The evaluation of potential actions starts from selecting a suitable desired context d D as the goal. The order which D are evaluated is determined first by the desirability value of each d, then by the Euclidean distance to the current context R The most specific a desired context d is, the higher the desirability. For instance, a specified desired context of (Warm Clean ) would be more desirable than de sired contexts of either Warm or Clean Therefore the system would try to evaluate potential actions that can lead to the (Warm Clean ) first, and seek paths to other desired contexts only after confirming it is unattainable from the current active contex t R 9.4 Capabilities and Limitations 9.4.1 Capabilities As the name implied, the key to the context driven programming model is context. In this model, instead of focusing on services to be delivered, or tasks and goals of each individual service, the sy stem strives to reach desirable contexts as specified by users. In some sense, the traditional definition of services are delivered through the specified transitions and intentions associated with each context. For instance, a typical climate control servi ce delivers by following specified conditions on when and how to control air conditioner and heater. In context driven model, users specify Warm as a desired context, and identify air conditioner and heater as the actuators capable of changing room tempera ture. The system can then automatically activate and

PAGE 126

126 deactivate them according to the currently active contexts, while driving towards and maintaining the temperature within the range specified as Warm This model takes an explicit approach in presenting t he goals, current states and the capabilities and limitations of means available in the system. The explicitness allows inconsistency and illogical instructions to be identified at both the compile time and runtime. In systems as dynamic and complicated as pervasive computing systems, the capability to detect erroneous implementation or specification is highly desirable and crucial to the effectiveness and stability of the system. More specifically, the context driven programming model possesses the followi ng capabilities: 9.4. 1.1 Detecting issues related to contexts and goals: 1. Detection of Irrational D esires and Goal s: A rational user should know what she/he desires and loathes, and the system can only assist a user when the contexts of desire and avoidance are specified in an unequivocal way. The system needs to and can detect conflicting desires and fears as follows, D X = 2. Detection of Unattainable Goal: Since the action plan is evaluated and selected using admissible A* search algorithm, the system can always identify the optimal path to achieve the desired context if one exists. On the other hand, this means the sy stem will also be able to identify if the desired contexts specified by user are unattainable. 3. Detection of Contexts of Inaction: The ultimate goal of the system is to eventually arrive at desired contexts (D), and the mean to achieve that is through inten tions specified at each context. Therefore for any context that does not belong to D, there should always be intentions aiming at moving towards D. The contexts of inaction are those non desired contexts without any intention or plan to get out of the curr ent situation. The existence of these contexts be identified and ramified. These contexts can be detected as follows, {C | I(C)= C D} 4. Detection and Handling of Impermissible C ontext: Because the dangerous and undesirable impermissible contests ( X ) ar e explicitly defined by users, the detection of when the danger presents itself is trivial. If any currently active context ( R ) belongs to X the danger is imminent. Since the action to handle such occurrence is defined an interpretation function: I: X S the emergency handler will not be interrupted, conflicted or have to compete with other services

PAGE 127

127 Detecting issues related to intentions and actions: 1. Detection of Conflicting Directives: Using the description of an intentional effect it is straig htforward to identify whether or not two actuators conflict with each other. Two actuators a i and a j are in conflict in context u if g i ( u ) g j ( u ) = That is, t he invocation of a i leads to a state of the world that is disjoint from the state to which the invocation of a j will lead, hence this state of the world can never arise. A classical example of the invocation of two conflict ing actuators is the air conditioning and the heater. A heater will raise the room temperature whereas an air conditioner will lower the temperature hence a statement that activates both the air conditioner and the heater at the same time is considered to be contradictory 2. Detection of illogical intentions: Based on Definitions 14 and 20, we can now systematically decide whether that leads away from all desired contexts, then such an intention would not benefit the space or the user at all. Such intention is then considered to be illogical, and can be detected by: As sume R is the currently active context, then illogical intention i I can be identified as follows: dist(R, d) < dist([ I 1 g i](R), d), d D Strong adherence to u ser centric computing : Examining the definition of programmable pervasive space P ::= where B + is defined by B + ::= re veals how user centric computing is placed at the core of this model. In the four tuple representing P B + represents the user, R is the set of currently active contexts as interpreted by I S is the resulting actions to be taken, defined by the intentions of the user I:C S The only element not directly related to user is the 2 A which is determined by the availability of the actuators in the space, and indirectly affected the accumulated ac tions S taken over time. At the core of this model, it is all about how users interpret the sensory data collected, what they want to achieve and to avoid, and the preferred actions they believe can take them closer to the goals and farther from the hazard s. There is a sharp contrast to the service oriented model, in

PAGE 128

128 which each service has its own agenda and goals, and these goals and the means to deliver the within medicine reminder) in their homes, cars and other private settings, therefore it is even more crucial to make sure the system is built around users to support and assis t them in a way they prefer. Better u nderstanding of the system One of the most telling features of this programming model is the explicitness of the knowledge representation. As we establish this model, each element in the system is formally defin ed, and it is shown that during the 4 step programming procedure, majority of efforts were spent on explicitly defining the capabilities of sensors and actuators, interpretation of sensor readings, identification of the desired and impermissible contexts, intentions when certain contexts become active. The system takes all the information to compose the space wide context grid that can describe all possible contexts of the space and the currently active ones. Through this process, we e xplicitly learn the relevant information about the sensors, actuators, users and the space. Unlike its service oriented counterparts, this model does not embed the knowledge about devices to use, the goals to achieve or the current state of the space in co de segments, which users rarely have access to. This explicit understanding is especially beneficial considering the dynamicity and heterogeneity of typical pervasive computing systems. Our early attempt in realizing this model with a programming procedure requires programmers to specify intentions for each single context, whether atomic or derived 49 50 Although th e process can be mitigated with aggregations of related contexts, as the number of domains grows, the number of derived context s inevitably exp lodes exponentially.

PAGE 129

129 The new program procedure introduced here drastically reduces the programming complexity from exponential to linear. Each task in the programming procedure and its complexity is presented as follows: 1. Identify domains and atomic context s: O(i) where i is the number of domains of interest. 2. Associate sensors and actuators with domains: O(j+k*i) in the worst case scenario, where j and k are respectively the number of sensors and actuators, and i the number of domains. 3. Identify the desired and impermissible contexts: O(1) this is only associated with 4. Specify the intentions: Instead of specifying the action sequence statement for each possible context, the new procedure requires users to only identify the intention of intentions is only O(i) plus a constant O(1) for specifying overriding intentions for specific derived c ontexts. This tremendous reduction to linearity in the programming effort required makes this a much manageable and realistic procedure. Compared to a more traditional service oriented programming, this may require some time to analyze and specify each se nsor, actuator and identify true intentions at first. But this is no more complicated than other models, as these processing are also part of programming with services, albeit in a more implicit form. A great potential exists for this model to incorporate AI and optimization techniques. Since users only need to specify their intentions, and it is up to the system to analyze available computing system into a path fin ding problem, plenty of existing algorithms and AI techniques can be used to model and discover the optimal way to provide services to users and achieve their desired goals. Last but not the least, with all contexts, including both atomic and derive ones, layout on the context grid, users can easily grasp the snapshot of the current state of the space ( R ). System

PAGE 130

130 programmed using service oriented models usually require making queries and checking up on various services to get partial contextual information. The fact that intentions and action statements are associated with each context, further allow users to examine currently executing actions as well as other options that are not chosen. 9.4.2 Limitations The context driven programming model offers a clean abstract and explicit approach to implement pervasive spaces. Due to the nature of context and the inherent reactive characteristics, there are limitations to the effectiveness of this model under certain circumstances. Limitation 1. Lack of support for decision makin g based on history and derivatives The trigger for any decision made with this model hinges on currently active contexts. The design does not include memory or storage for historic data, therefore implemented systems can only respond to snapshots of curre nt states but not the path and events leading to the current contexts. Many practical applications depend on the availability of such history. For instance, the detection of a person standing on the door mat at the front door alone provides insufficient in formation regarding to whether the appropriate action should be to open or close the front door. Such a decision can only be made provided information regarding whether the person has come in from the outside, or approaching the door within the house. This limitation can be mitigated with the defining derived contexts based on the past history, introducing temporal logic into the model, or allowing history to be handled at the device level (sensors and actuators). Limitation 2. Lack of support for portable service(s) As services are not represented as singular components within this model, but instead scattered as a series of transitions and intentions among contexts. It is by no mean an easy task if one were to attempt porting a particular service to other pervasive spa ces. Furthermore, as the entire context grid is highly customized to each user and incorporated with the beliefs, desires and intentions of individual user, therefore creating new pervasive computing systems for a new user incur relatively higher initial c ost. Although the inherent characteristic prevent services from being easily contexts, the portability of services is really not an issue, as long as the space can satisfy Limitation 3. Programmer acceptance Majority of contemporary programmers were trained to implement software using object oriented or procedural programming languages. Traditionally, programmers are given the responsibility and power to

PAGE 131

131 specify the detail s of conditions and executions. They examine the purposes of the software or services, and dictate how these goals are to be achieved through a series of tasks under various specified conditions. When following the context driven programming model, program mers are instead being asked to think and reactive, non goal oriented thinking process is unconven tional, and the granularity of conditions and control criteria are defined by the resolution of defined contexts. Both can result in acceptance and adjustment issues from experience programmers. 9.5 Scenario Matilda is an 85 year old lady, living alone in a free standing smart home. Though suffering from asthma, she does not require continuous live in assistance. Instead, the services in the smart house monitor and control the indoor environment to reduce her risk of suffering an attack. Should any dangerou s condition which can lead to asthma attack arise, the system will attempt to resolve or mitigate the problems, or at least alert her to the danger and cue her for response. On a frosty January night, Matilda returns from a long vacation and family gatheri ng, as she enters through the door, the house sprints back to life, and the system hustles to make Matilda feel right at home. The remainder of this section describes the development of this assistive service using our context driven programming model. The most critical risk factors which can trigger asthma episodes are air quality and temperature. In order to keep Matilda healthy, the smart house constantly monitors and adjusts these two parameters. To keep everything in working order, the smart house also needs to monitor the power draw to prevent blown fuse. According to the ontology used to define contexts, there are five atomic contexts in the Temperature domain ( D temperature ), which are Freezing Cold Warm Hot and Extreme Heat with Warm being the preferred context. of Cold Warm and Hot are somewhat warmer than those of other people (Figure 8 1). Inside her

PAGE 132

132 bedroom, there is a thermometer that monitors the room temperature with the resol ution of 0.1 which can be represented as follows, f thermometer : U D temperature ( U represents the overall sensible state of the house) where D temperature {32 + i 0.1 } i N | f thermometer ( u ) f thermometer ( u p )| p:=where the thermometer is insta lled, bedroom As a general rule, she prefers warm climate, therefore the services in the smart house attempt to bring the temperature up when the room is cold or freezing, and strive to lower the she should always avoid Freezing temperature or Extreme Heat and stay away from Dusty air condition. If possible, she should always remain in environment that is either (Warm Sterile ) or (Warm Clean ) These preferences and limitations can be clearly specified and represented in a 3 dimentional context cube (Figure 8 6). The current state of the house can be represented by the active context of the space R, which consists of the contexts that can be observed and are currently true. Right after Matilda enters her house R = { F reezing Dusty Low Power Draw }. Since both Freezing and Dusty contexts represent health hazards, the home serve has to formulate a plan to remove the house from the Freezing state, and p referably move towards either (Warm Sterile ) or (Warm Clean ) Looking up the context grid, as shown in Figure 8 3 the home server intention is to get the house to Cold from Freezing state, and to Clean state from Dusty state. In order to honor her intentions, appropriate actuators have to be located. In this case, the home

PAGE 133

133 server finds three actuators, air conditioner, central electric heater and ceramic space heater, associated with the domain D temperature In particular, the cer amic space heater as expressed below, is capable of raising the temperature to the range corresponding to the context of Cold : U U (u)= { y | y { 50 + i 1 }, i N } (u) > Id u where Id u is the identify function, u | (u ) (u pa )| p a := where the heater is currently located at, bedroom where represents the overa ll intentional effect of the heater in terms of temperature, taking into considerations of the environment, such as the current temperature and air circulation. We also know that the space heater draw considerable amount of power when turned on, which is e xpressed as follows, (u)=u + 800 W. The home server also identifies the existence of an ionic air purifier that can capable of improving air quality, which would draw a modest additional power of 55W. Having gathered the informatio actuators suitable to fulfill these intentions, the home server would now start to evaluate the optimal action plan. The execution of A* algorithm indicates that the first priority is to transit ion the house through a diagonal path to (C old Clean ) context, as both Freezing and Dusty are considerable to be impermissible. From (C old Clean ) context, there are paths that can lead to the desirable (Warm Sterile ) or (Warm Clean ) contexts The home server further identifies

PAGE 134

134 that ceramic spac e heater and ionic air purifier as the actuators that can make these transitions happen. Ceramic space heater is chosen instead of central electric heater unit because it draws less power, and will not trigger the impermissible context of High Power Draw This modeling and programming procedure allows the system to detect problematic implementations at the design time. For instance, if a user specifies Warm as a desirable context (belongs to D ) and Dusty as an impermissible context (belongs to X ), then the desirability of the derived context (Warm Dusty) becomes ambiguous. The system can easily run a scan to make sure all goals are rational and no context has been specified as both desirable and dangerous ( D X = ). Remedial actions can be taken to reso lve these issues when users are alerted with a warning. If a user forgets to specify the preferred transition is to make the house Warm when it is Cold then once the house reaches the active context of (Cold Sterile Medium Power Draw ) the home server will not know what to do next, although it is obvious from the context grid that the currently active context is not what Matilda prefers. The smart home has reached a context of inaction, and cannot further improve the environment towards more favorable conditions. In this case, the omission of this intentions specification also makes it impossible to find a viable path from the initial context of (F reezing Dusty Low Power Draw ) when Matilda first enter the door and reach the desirable contexts of (Warm Sterile ) or (Warm Clean ) In either case, the system can detect the potentially problematic implementation that result in context of inaction or unatt ainable goals at design and implementation time. One of the most obvious but critical capability is the ease to explicitly define harmful situations as impermissible contexts ( X ) at the time of programming, which also allows the home server to efficiently and unequivocally recognize the danger at runtime and take swift actions to

PAGE 135

135 move the system out of these contexts. We can also observe from this scenario how the entire operation of the smart house is completely personalized. From the interpretation of con texts, to the definition of goals and danger, and the specification of preferred action plan under various situations, users have total control in specifying and customizing how a pervasive computing system can better serve their needs. Our research on sys tem safety for pervasive computing systems starts with designing safety enhancements that are better suited to be integrated and adapted by the currently most popular approaches based on services. Although these measures certainly make developers more cons cience about the safety issues, while reducing the probability of and improving the response to the occurrence of safety risks, we want to present an alternative that is inherently superior in providing safety guarantees. Context driven programming model p resents a viable alternative approach because of its broader perspective to grasp at the big picture, resulting in an inherently stronger capability to prevent, detect and handle safe risks. Table 9 1 Comparison between service o riented and context driven programming models Service oriented Programming Model Context driven Programming Model Basic element Service Context Goal Achieve service goals Maintain preferred state Aggressiveness Proactive Reactive Ease of pr ogramming More intuitive, more fine grained control Piecemeal, less intuitive Safety guarantee Externally enforced More naturally incorporated Knowledge representation Inherently implicit (incorporated in the code) explicit Advantages Fine gra in control Explicit goals Less conflict Provide grand picture

PAGE 136

136 Figure 9 1 Domains and contexts of interest Figure 9 2 Associating sensors and actuators with domains Figure 9 3 Intention specificati ons D 1 :temperat ure freezing cold warm hot extreme heat D 2 : air quality sterile clean dusty D 3 : power draw low medium high ( Dusty Cold) ( Clean Warm) derived context D 1 :temperature ( ) freezing cold warm hot extreme heat 32 120 f 1 1 : thermometer 50 100 ha 1,1 : space heater 40 80 ha 2,1 : air conditioner 45 90 ha 3,1 : central heater D 2 : air quality ( ppm ) sterile clean dusty 0 1000 f 2 1 : particle counter 1 9 ha 4 ,2 : ionic air purifier 3 21 h a 5 ,2 : exhaust fan D 3 : power draw (W) low medium high 0 1600 f 2 1 : power meter 800 ha 1,3 : space heater 1200 ha 2,3 : air conditioner 1500 ha 3,3 : central heater 80 ha 4 ,3 : ionic air purifier 35 ha 5 ,3 : exhaust fan D 1 :temperature ( ) 10 freezing 40 cold 70 warm 90 hot 110 extreme heat 130 D 2 : air quality ( ppm) 0 sterile 3 c lean 20 dusty 70 D 3 : power draw (W) 0 low 800 medium 1600 high 4000

PAGE 137

137 Figure 9 4 Construction of high dimension context grid Figure 9 5 Potential action evaluation in the system Figure 9 6 Three dimension al context grid of the scenario Impermissible context X Desirable context D Current active context R Impermissible context X Desirable context D Current active context R D 1 :temperature freezing (1) cold (2) warm (3) hot (4) extreme heat (5) D 2 : air quality sterile (3) clean (2) dusty (1) D 3 : power draw (W) low (3) medium (2) high (1 ) D 2 sterile (3) Warm Sterile High PowerDraw clean (2) dusty (1) freezing (1) cold (2) warm (3) hot (4) e xtreme heat (5) D 1 high power draw (1) medium power draw (2) low power draw (3) D 3 Freezing Cold Warm Hot X Heat Sterile Clean Dusty High Power Medium Power Low Power R X D X

PAGE 138

138 CHAPTER 10 CONCLUSION AND FUTUR E WORK S afety is defined in the Merriam Webster dictionary as the condition of being safe from undergoing or causing hurt, injury or loss. For pervasive computing systems, especially those depl oyed in intelligent environments, the con siderations over safety should not be any less important than the effectiveness or usability of the system. Pervasive computing systems has the ability to influence the physical world, and often interact with their users in a much more intimate way than traditional systems, hence any unsafe operation c ould cause drastic physical and psychological damages. Even w ith all the assistance and convenience that come with the m the ir in troduc tion should not result in unreaso nable or unnecessary increase in safety risk s We have all learned from our own experience that, total safety guarantee is not possible for any system, natural or manmade, and certainly not applicable for pervasive computing systems either. A realistic obj ective is to enhance the capabilities to reduce, detect and handle a variety of safety risks. These systems should not bring unjustifiable risks to users, properties and processes, and they should be capable of providing warnings and handling risks should they arise. On top of all these, the solution has to be scalable and yet financially feasible. The inherent natures of dynamicity, complexity, heterogeneity and uncertainty associated with pervasive computing systems pose serious challenges in safety enhan cement The lack of reliable monitoring and arbitration mechanism s such as the ones available in various operating s ystems is one of the primary contributors to th is problem. The research has accomplished the following, Contribution 1. Bring the awareness on safety issue to the community. Contribution 2. Perform system analysis and cons truct formal models of all four fundamental elements in typical pervasive computing systems.

PAGE 139

139 Contribution 3. Identify the potential safety risks and common risk factors behind them. Contribution 4. Design and implement safety mechanisms that can identify and prevent potentially unsafe system implementation at the design time, and monitor safety risks and handle hazards during runtime. Contribution 5. Devise the software practice and programming tools to incorporate safer system architecture and risk hand ling capability during the design and implementation of new systems. Contribution 6. Explore an alternative context driven programming model that can more naturally and easily limits and monitors safety risks. Since safety issue is one of the major hurdles preventing perv asive systems from being widely adopted, we believe the proposed enhancement s in safety and reliability can go a long way in earning the trust of general public on this emerging technology. Having established safety as a critical issue in the research comm unity, and taking the first steps to enhance the safety features of pervasive computing systems, we have opened up a whole new venue of research opportunities in overcoming challenges to make smart spaces safer places. Some of these possibilities include, 1. Countermeasure for newly identified safety risks: As new applications are developed and more installations deployed, hidden and new risk factors would be revealed and created. It is expected that, similar to research on network and computer security, conti nuous efforts will be required to identify and remedy these new safety risks. 2. Protection against malicious attacks: The focus of this study is safety risks resulting from system design and implementation flaws, as well as uncontrollable risk factors. As pe rvasive computing systems gain more control over facilities with higher value, such as advance laboratory or even financial institutions, and collect more valuable private information, such as medical data or personal history, the incentive for malicious a ttacks dramatically increases. A separate study is required to understand the difference between ensuring safety under these highly sophisticated attacks as compared to system failures or accidental safety hazards. 3. Establishing safety evaluation test bed: An objective, impartial test bed and a well established safety evaluation procedure is a must, so people can begin to understand and stay informed about the safety risks of the systems they install in their houses, offices, cars and hospitals.

PAGE 140

140 Pervasive co mputing is the computing paradigm of the 21 st century 1 with the promise of seamless integration of computation and communication disposal Mission critical services, assistance to the elderly and disabled, and the p romise of unforeseen convenience and enhanced experiences, have demonstrated how this emerging technology is posed to change every aspect of our daily lives. However, before we can truly embrace it, we need to know pervasive computing technology will not o nly take us to a better place but also a safer ground. Our research effort leads us towards that direction, but plenty remains to be done before we can declare safety for users, properties and processes in any intelligent environments.

PAGE 141

141 APPENDIX A SEMANT IC DESCRIPTION FILES A.1 Service Services (including devices represented as services in SOA) are by far the most complicated entity in any pervasive computing systems. Explicitly represent and annotate their complex characteristics and the knowledge associ ated with them in a single file is both unwieldy and inefficient. The better solution is to divide these semantics into a set of descriptions files. Together, they present multiple facets of a single service. The list of the files and the type of informat ion included in each is presented as following: Interface file Supported methods Manifest file Software Information [H|M] Service Name [H|M] Service Version [H] Service Vendor [H] Service Author [H] Service Description Service Essentials [H|M] Service Activator [x.jar] Service Dependencies [H|M] Import Package [H|M] Export Package

PAGE 142

142 Service Type [H|M] Device/Service/Utility/Others [H|M] Effective Domain Service Mode [H|M] Automatic/Manual Miscellaneous [H|M] Jar file name Other Available Info [H|M| OPTIONAL] Widget file [H|M| OPTIONAL] Remote Control Element file DEVICE ONLY [H|M] Device type: Sensor/Actuator/Both [H|M] Device descriptor file [H] Device Description Service description file Op eration conditions Upper, lower bound, valid choices, handling strategy Binding Info Alignment Info Mandatory alignment Preferable alignment Dynamic info Implementation class Utility

PAGE 143

143 Build.xml A few s ample semantic description files for se rvices and devices are presented as following, S ample Interface File // package edu.ufl.icta.sensors.sensible ; import *; public interface Sensible Sensor { public int get Reading(AtlasClient ac); public int subscribeToData(AtlasC lient ac); public int unsubscribe Data(AtlasClient ac); public long getStartupTime(); public boolean onEmergencyPowerDown( Object arg ); public void submitEvent(Event event); public Object getServiceInfo(Object arg); public Status getStatus(); } S am ple Manifest File // Bundle SymbolicName: SENSIBLESensor Bundle Version: 1.0.0 Bundle Name: SENSIBLE Sensor Bundle Vendor: www. Bundle Author: Sensible Programmer Bundle Description: Service for accessing Sensible Sensor Bundle Activ ator: edu.ufl.icta.sensors.sensible.impl.Activator Import Package: org.osgi.framework, Export Package: edu.ufl.icta.sensors.sensible Interface: edu.ufl.icta.sensors.SensibleSensor Service Type: Device Effective Domain: Tempera ture, Humidity Service Mode: Automatic Jar File: SensibleSensor.jar Widget File: SensibleWidget.xml Remote File: SensibleRemote.xml Device Type: Sensor Descriptor File: SensibleSensor.xml Device Description: UF1 Sensible Sensor. Produces sensible reading S ample Device/Service Descriptor File // SensibleSensor.xml < > 100 400

PAGE 144

144 saturation
hertz 3 FlipflopHandler
Temperature Sample Widget Descriptor File [ Optional Omitted ] Sample Remote Descriptor File [OPTIONAL, OMITTE D] Sample Build File //build.xml [OMITTED] A.2 User It is crucial for the context awareness and customization of the system, that proper, concise and sufficient user profiles are collected to digitally represent users in a system. The information of intere st to the systems includes static profile, such relevant personal information of the user, including the preference, limitations, and how one interprets certain applicable contexts; the location, current biometrical data, and the history of interaction with services and devices in the system. The type of information included in both static and dynamic profiles are presented below: Static profile User ID Gene ral User info pertaining to pervasive computing environments

PAGE 145

145 Interactive? (for being asked to provide further info during execution) Context (preference) Context (impermissible/limitation) Handling routine Dynamic profile Dimension Data A fe w sample semantic description files for user s are presented as following, Sample User Profile //Demo.pfl 1 Demo true Hot atomic Demo.rul < /context_interpretation_file> Sample Context Interpretation File //Demo.rul < interpretation_rule > Hot 85 105 Fahrenheit atomic Warm 85 60

PAGE 146

146 Fahrenheit atomic quiet 50 20 Decibel Indoors atomic A.3 Space In order to understand the environment in which a pervasive comp uting system is operating, there needs to be ontology and rules of interpretation. These semantic description files for space provide the framework for all the services and devices to function and interact properly based on a common understanding. Space De scriptor File Ontology file Including interpretation of atomic context derived context Interpretation file (data atomic context) Impermissible context specification Handling routine A few sample semantic description files for a space are presen ted as following, Sample Space Descriptor File // MachineRoom.des 32 machine room Workspace.ont Hot atomic Machineroom.rul < / space>

PAGE 147

147 Sample Interpretation File < interpretation_rule > Hot 85 105 Fahrenheit atomic Humid 75 100 Numeral atomic quiet 50 20 Decibel Indoors atomic

PAGE 148

148 APPENDIX B As mentioned earlier in Chapter 8, there are three different types of programmers in a pervasive computing system, service programmers, space programmers and end users. The heavy duty progra mming exercises are mostly performed by service programmers. The authoring tool implemented as part of this research exists as a plug in to the popular open source IDE, Eclipse. The functionalities and support provided by th e latest version 2.0 of th is too l has already been summarized in Section 8.6, which also highlights discussions on the design choices and other considerations. This appendix is intended to provide more detailed step by step instructions on how service programmers can utilize this authori ng tool to implement or update their services. This tool is a major component of the overall service authoring tool within the Atlas architecture, which also includes a device description language and device service generator. An overview on this set of au thoring tools as well as the latest programmers manual can be found at This authoring tool set is also compliant with, and will serve to create reference implementations of an open standard, service oriented device architecture (SODA). The details of this standard and the coalition/organization behind this standard can be found at http://www.sen The programming process of a new service is organized into a six step process: 1. Creation of a new project 2. Creation of semantic files 3. Specification of dependent bundles and projects 4. Filling in the Service Logic into the Generat ed C ode T empl ate 5. Compilation and verification 6. Deployment into a runtime system T hese six steps can be succinctly explained as following:

PAGE 149

149 B.1 Creation o f a N ew Project As with any other Java projects created using Eclipse, programmers start by creat ing a new project and the plug in will setup the corresponding direc tories and file structures The ver sion 2.0 of this plug in does not automatically assume all other projects within the same workspace are part of the dependency requirement for the newly created OSGi service project. B.2 Creation o f Semantic Files As already discuss ed in the Appendix A, it is crucial that the semantic knowledge about the service, device and users are explicitly expressed so as to avoid misunderstanding and enhance the interoperability in highl y dynamic pervasive computing environments. As part of the project creation process, important semantic description and project management fi les are created using templates programmers are then asked to fill in the necessary information into these created files as an integral part of the service implementation process. These files include : .project file This file describes the attributes of a project .classpath file This file describes the classpath of all dependent resources at the time of compilation M anifest file This file annotates generic information and attributes about the bundle (to be filled in by programmer s ) as well as the package dependency B uild file: This file contains information on how and what to be compiled and included into the fin al service bundle S ervice descriptor file: This file annotates and describes the detailed information about the services, such as the methods supported, parameters, service dependencies, user requirement alignments as well as emergency handler specificati ons L ogging property file: This file denotes the various aspects of the service log, including the level of details and the location of where the log is to be stored B.3 Specification o f Dependent Bundles a nd Projects Services built on SOA exhibit heavy dependencies. They require the existence of other services to support the ir own proper functioning. Programmers can either specify these

PAGE 150

150 dependencies in the service descriptor file, or they can also use drag and drop operation s from the front end to includ e additional bundles and services as dependent entities. Either way, the plug in would attempt to retrieve these necessary bundles so the service can compiled proper ly B.4 Filling in the Service Logic into the Generat ed C ode T emplate Instead of generating the entire code t hat includes every function, the design of the software structure is to place as much of the code associated with OSGi bundle related operations and safety mechanism invocations to base classes, hence maintaining a minimal and clean exten ded classes in the template when presenting to the service programmers. The ultimate objective is to allow programmers to implement services as easily and straightforward as regular java applications without having to worry about these additi onal mechanism s. The plug in populates certain relevant information from semantic files into the generated code template both to assist the programmers as well as maintaining consistency between the semantic files and the code. The changes made in the code template in t his step are likewise used to update the semantic files where the information might come from. The basic code structure in these generated code templates already includes separate methods for operations such as state transitions and emergency handler metho ds. Service programmers would only need to fill in the service log ic in appropriate methods created as part of the templates. B.5 Compilation and verification After the completing the coding and the semantic files specification service programmers can the n begin to compile the code and the files into a service bundle in the form of a jar file Before the new service can be compiled the plug in performs a series of verification, such as the support of the Service Safety API, the provisioning of the emergen cy handler, and the conformance of semantic descriptions files to their respective schemas. Although the correctness

PAGE 151

151 of the actual logic implementations for these handlers is the programmers responsibility the step of verification ensures that at least s ome sort of procedures is provided when the worst has come to happen. After the program is verified it is then compiled into a single service bundle and ready for deployment B.6 Deployment into a runtime system The plug in provides the functionality such that with a single press of a button, the compiled service can be directly deploy ed to a n OSGi framework.

PAGE 152

152 Start Design Implementation Verification/ Compilation Deployment End Impl. emergency handler Impl. Safety API Desc. File Verified Compilable yes yes yes n o n o n o n o yes M anifest File S ervice Descriptor File B uild File Implementation Class I nterface Misc. Info Include/Convert documented design spec Review design against service objectives spec Implement service logic Implement emergency handler Define service objectives Devise service logic I dentify resource and dependency Design software architecture Detail ed design Operational parameters Service Logic Dependency/ Resource C ustomization M ethods / Interfaces D ynamic Info G eneral Service Info O ther Info Fig ure B 1 Flowchart for programming services

PAGE 153

153 LIST OF REFERENCES 1. Scientific American Vol. 265, Issue 3, Sept. 1991, pp. 66. 2. N. Gershenfeld R. Krikorian, Scientific American Vol. 291, Issue 4, Oct. 2004, pp. 76 81. 3. N. Leveson, Safeware: System Safety and Computers Addison Wesley, 1995, pp. 22, 313 44 6. 4. IEEE Internet Computing vol. 8, issue 6, Nov. 2004, pp. 93. 5. A. Helal, W. Mann, H. Elzabadani, J. King, Y. Kaddourah and E. Jansen, "Gator Tech Smart House: A Programmable Pervasive Space," IEEE Computer magazine March 20 05, pp 64 74. 6. IEEE Pervasive Computing Magazine Vol. 5, No. 4, Oct. Dec. 2006, pp. 20 27. 7. sive Computational Science ICCS 2005 Springer Verlag, 2005, pp. 1068 1071. 8. C. Rougier, J. Meunier, A. St Arnaud and J. Ro Proc. of the 21st International Conference on Advanced Information Networking and Applications Workshops (AINAW '07) Niagara Falls, Canada, May 2007, pp. 875 880. 9. A Dependability in Sensor Based Context Proc. of the 38th Annual Hawaii International Conference on System Sciences (HICSS'05) Track 9, 2005, pp. 290a. 10. Y. Yuan Z. Miao and S. Hu Proc. of 2006 IEEE Region 10 Conference (TENCON 2006) 2006, pp. 1 4. 11. P. Kannadiga, Proc. of the International Conference on Volume II, 2005, pp. 277 282. 12. A. Helal, M. Mokhta ri and B. Abdulrazak, The Engineering Handbook on Smart Technology for Aging, Disability and Independence John Wiley & Sons, ISBN 0471711551, Computer Engineering Series, 2007.

PAGE 154

154 13. to the Proc. of the ninth annual IEEE International Symposium on Wearable Computers, Osaka, Japan, October 2005. 14. B. Abdulrazak M. Mokhtari M. A. Feki and M. Ghorbel Proc. IEEE ICTTA, Damascus, Syria, April 2004. 15. S. Hodges, L. Williams, E. Berry, S. Izadi, J. Srinivasan, A. Butler, G. Smyth, N. Kapur Proc. of the Eighth International Conference on Ubiquitous Computing (UbiComp 2006) Orange County, CA, USA, 2006, pp. 177 193. 16. D. J. Cook and S. Das, Smart Environments Wiley Publisher, 2005. 17. G. D. Abowd A. Bobick I. Essa E. Mynatt and W. Rog ers Proc. AAAI Workshop and Automation as a Care Giver Alberta, Canada, July 2002. 18. D. Stefanov Z. Bien and W. Bang Physical Disabilitie IEEE Trans. Neural Systems and Rehabilitation Engineering Vol. 12, No. 2, 2004, pp. 228 250. 19. H. Pigot A. Mayers S. Giroux, B. Lefebvre V. Rialle N. Noury and cognitive i Proc. UbiCog Gteborg, Sweden, Sept. 2002. 20. N. Noury G. Virone, T Proc. Second IEEE EMB Special Topic: Microtechn ologies in Medicine & Biology Madison, Wisconsin, USA, May 2002, pp 318 321. 21. Advanced Specialization and Analysis for Pervasive Computing project deliverable report D13, 2003. 22. J. Bohn F. Grtner and H. Vogt First International Conference on Security in Pervasive C omputing, LNCS 2082 Springer Verlag, Boppard, Germany, March 2003, pp. 53 70. 23. Y. Proc. IEEE International Conference on Vehicular Electronics and Safety, 2006, (ICVES 2006) Dec. 2006, pp. 3 33 336. 24. National Univ. of Defense Tech, China, 2004.

PAGE 155

155 25. Report, NIST, 1996. 26. F. Holz Vehicular Electronics and Safety, 2006, (ICVES 2006), Dec. 2006, pp. 289 294. 27. J. Wang, F. Gao on Multi IEEE International Conference on Vehicular Electronics and Safety, 2006, (ICVES 2006), Dec. 2006, pp. 194 198. 28. P. Green, "Driver Interfaces for Vehicles of the Future and Usability Roadblocks to Their Introduction," Inside Automotives vol. 3, no. 6, 1996, pp. 33 36. 29. Interface Design of In Proc. IEEE International Conference on Vehicular Electronics and Safety 2006 (ICVES 2006) Dec. 2006, pp. 491 495. 30. K. Tindell, H. Kopetz, F. Wolf and R. Ernst, "Safe automotive software development", Proc. of Design, Automation and Test in Europe Conference and Exhi bition (DATE '03) 2003, pp. 616 621. 31. J. Qiang, Z. Zhiwei and P. Lan, "Real time nonintrusive monitoring and prediction of driver fatigue", IEEE Transactions on Vehicular Technology vol. 53, issue 4, July 2004, pp. 1052 1068. 32. M. Tian, F. Liu, W. Zhu, C. Proc. IEEE International Conference on Vehicular Electronics and Safety, 2006, (ICVES 2006) Dec. 2006, pp. 507 511. 33. SAE Recommended Practice Navigation and Route Guidance Functi on Accessibility While Driving (SAE J2364), Society of Automotive Engineers, Warrendale, PA: Society of Automotive Engineers. 2001, March 13 revision. 34. SAE Recommended Practice Calculation of the Time to Complete In Vehicle Navigation and Route Guidance Tas ks (SAE J2365), Society of Automotive Engineers, Warrendale, PA: Society of Automotive Engineers. 2001, March 13 revision. 35. Proc. 2nd w orkshop on Middleware for pervasive and ad hoc computing 2004, pp. 135 139. 36. C. Kunze, U. Grossmann, W. Storkand and K. D. Mller Biomedizinische Technik vol. 47 of Beitr ge zur 36. Jahrestagung der Deutschen Gesellschaft fr Biomedizinische Technik pp. 360 362.

PAGE 156

156 37. Proc. IEEE Symposium on Security and Privacy 1996 38. M. Roman, C. Hess, R. Cerqueir IEEE Pervasive Computing Vol. 1, issue 4, 2002, pp. 74 83. 39. Proc. IEEE Symposium on Security and Privacy 1996. 40. IEEE Internet Computing vol. 8, no. 6, Nov./Dec. 2004, pp. 69 79. 41. G. Krasner and S. view controller user interface paradigm in the smalltalk Journal of Object Oriented Programming Vol. 1. No. 3, 1988. 42. A Component System for Pervasive Proc. Second IEEE International Conference on Pervasive Computing and Communications (PerCom'04) 2004, pp. 67. 43. C. Srensen, M. Wu, T. Sivaharan, G. Blair, P. Okanda, A. Friday and H. Duran Limon, aware middleware for applications in Proc. 2nd workshop on Middleware for pervasive and ad hoc computing 2004, pp. 107 110. 44. Proc. Third International Conferenc e on Mobile Data Management IEEE Computer Society, Washington, DC, USA, 2002, pp. 146. 45. Proc. Fourth IEEE Workshop on Mobile Computing Systems and Applic ations IEEE Computer Society, Washington, DC, USA, 2002, pp. 94. 46. an informal companion volume of short papers of the Proc. First International Conference on Pervasive Computing Zurich, Switzerland, 2002, pp. 41 47. 47. Proc. First IEEE Dallas Fort Worth, Texas, USA, 2003, pp. 243 253 48. Proc. Fourth IEEE Workshop on Mobile Computing Systems and Applications IEEE Computer Society Press, New York, USA, 2002.

PAGE 157

157 49. H. Yang, J. King, A. Helal and E. Jan Driven Programming Model for Proc. 5th International Conference on Smart Homes and Health Telematics (ICOST) Nara, Japan, June 21 23, 2007, pp. 31 43. 50. niversity of Florida, Ph.D. dissertation, 2005. 51. aware Proc. Workshop on Software Engineering for Wearable and Pe rvasive Computing Limerick, Ireland, June 6, 2000. 52. the rapid prototyping of context Human Computer Interaction (HCI) Journal vol. 16, 2001, pp. 97 166. 53. context Proc. 1999 Conference on Human Factors in Computing Systems ( CHI '99 ) Pittsburg h, PA, 1999, pp 434 441. 54. aware applications in smart Proc. 2nd workshop on Middleware for pervasive and ad hoc computing 2004, pp. 111 116. 55. S. Yau, F. Karim, F. Wang, B. Wang and S. Gu sensitive IEEE Pervasive Computing Vol. 1, Issue 3, Jul. Sept. 2002, pp. 33 40. 56. Proc. 2nd works hop on Middleware for pervasive and ad hoc computing 2004, pp. 155 160. 57. middleware interaction to support Proc. 2nd workshop on Middleware for pervasive and ad hoc computing 2004, pp. 140 145. 58. Proc. 2nd workshop on Middleware for pervasive and ad hoc computing 2004, pp. 161 166. 59. G. D. Abowd, A. K. D better understanding of context and context Proc. 1st international symposium on Handheld and Ubiquitous Computing Springer Verlag, Berlin, Germany, 1999, pp. 304 307. 60. J. Hong an Human Computer Interaction, vol. 16, issue 2 4, 2001, pp. 287 303.

PAGE 158

158 61. Rapid Construction of UbiC Online Proceedings of the System Support for Ubiquitous Computing Workshop at the Sixth Annual Conference on Ubiquitous Computing (UbiComp 2004) Sept. 2004. 62. t aware IEEE Pervasive Computing Vol. 6, Issue 1, 2007, pp. 73 80. 63. T. Berners Scientific American vol. 279, issue 5. 64. oriented middleware for buildi ng context aware Journal of Network and Computer Applications (JNCA) vol. 28, 2005, pp. 1 18. 65. Proc. 3rd international conference on Mobile systems, applications, and services Seattle, Washington, 2005, pp. 219 232. 66. M. Addlesee, R. Curwen, S. Hodges, J. Newman, P. Steggles, A. Ward and A. Hopper, IEEE Computer Magazine Vol. 34, No. 8, August 2001, pp. 50 56. 67. C. Kidd, R. Orr, G. D. Abowd, C. G. Atkeson, I. Essa, B. MacIntyre, E. Mynatt, T. Starner Proc. of Cooperative Buildings 1999, pp. 191 198. 68. A. Helal, W. Mann, H. Elzabadani, J. Ki IEEE Computer magazine March 2005, pp. 66 74. 69. A. Holmes, H. Duman and A. Pounds Proc. Interna tional Test and Evaluation Association (ITEA) Workshop Virtual Home Environments ITEA Press, 2002, pp. 30 37. 70. H. Hagras, V. Callaghan, M. Colley, G. Clarke, A. Pounds Cornish and H. Duman, intelligence environment using embedded agent IEEE Intelligent Systems Volume 19, No. 6, 12 20, Nov./Dec. 2004. 71. centred Proc. IEE International Workshop on Intelligent Environments Colchester, UK, 2005, pp. 267 275. 72. M. Fleck, M. Frid, T. Kindberg, E. O' Brien IEEE Pervasive Computing Vol. 1, Issue 2, April June, 2002, pp. 13 21.

PAGE 159

159 73. F. Bel IEEE Pervasive Computing Vol. 1, No. 2, April June 2002, pp. 33 41. 74. book: translating th Proc. 2004 conference on Human factors in computing systems Vienna, Austria, 2004, pp. 25 32. 75. L. Arnstein, G. Borriello, S. Consolvo, C. Hung and J. Su, Labscape: A Smart Environment for the Cell Biology Laboratory IEEE Pervasive Computing vol. 1, no. 3, July September 2002, IEEE Computer Society, NY, NY. 76. T. Hansen, J. Bardra IEEE Pervasive Computing Vol. 5, Issue 3, July Sept. 2006, pp. 24 31. 77. IEEE Pervasive C omputing Vol. 5, Issue 4, Oct. 2006, p. 20 27. 78. Communication of the ACM Vol. 48, No. 3, 2005, pp. 15 16. 79. S.Duri, M. Gruteser, X. Liu, P. Moskowitz, R. Perez, M. Singh and J. M. Tang, Proc. 2nd International Workshop Mobile Commerce (WMC 02) ACM Press, 2002, pp. 25 32. 80. IEEE Pervasive Computing vol. 3, issu e 4, 2004, pp. 34 41. 81. DaimlerChrysler Corporation, DaimlerChrysler Research and Technology North America, IT Cruiser Telematics Concept uses Jini Technology White Paper Jan. 2001. 82. sor Proc. 1st ACM International Workshop on Wireless Sensor Networks and Applications Sept. 2002, pp. 88 97. 83. aware Electronic Tourist Proc. SIGCHI conference on Human factors in computing systems CHI 2000, Netherlands, April 2000, pp. 17 24. 84. T Y. Sohn, A iCAP: An Informal Tool for Interactive Prototyping of Context Aware Application, Ext ended Abstracts of CHI 2003 2003, pp. 974 945. 85. T. Weis, M. Knoll, A. Ulbrich, G. Mhl and A. Brndle, "Rapid Prototyping for Pervasive Applications," IEEE Pervasive Computing vol. 6, no. 2, Apr. June 2007, pp. 76 84.

PAGE 160

160 86. K. Martinez, J Hart and R vironmental s ensor n IEEE Computer Magazine vol. 37, issue 8 Aug. 2004, pp. 50 56 87. J. Xia, C. Chang, T. Kim, H. Yang, R. Bose and A. Helal, "Fault resilient Ubiquitous Service Composition," Proc. 3rd IET International Conference on Intelligent E nvironments (IE'07) Ulm University, Germany, Sept 24 25, 2007 88. H. Yang, R. Bose, A. Helal, J. Xia, and C. Chang, "Fault resilient Pervasive Service Composition", Advanced Intelligent Environments H. Hagras, eds. Springer Verlag, t o appear 2008. 89. The Des cription Logic Handbook F. Badder, D Calvanese, D McGuinness, D Nardi and P Patel Schneider, eds., Cambridge University Press 2003. 90. R. Kumar, M. Wolenetz, B. Agarwalla, J. Shin, P. Hutto, A. Paul and U. Ramachandran, DFuse: A Framework for Distribut ed Data Fusion Proc. first international conference on Embedded networked sensor systems Los Angeles, CA, 2003, pp. 114 125. 91. M Wooldridge Reasoning about Rational Agents The MIT Press, Cambridge, Massachusetts /London, England, 2000. 92. S MacClure, J Scambray and G Kurtz, Hacking exposed 3rd ed., Osborne/McGraw Hill, 2001. 93. R. Bose, A. Helal, V. Sivakumar and S. Lim, "Virtual Sensors for Service Oriented Intelligent Environments," Proc Third IASTED International Conference on Advances in Computer Science and Technology Phuket, Thailand, April 2 4, 2007. 94. T. Gu, H. Pung Toward an OSGi Based Infrastructure for Context Aware Applications IEEE Pervasive Computing vol. 3, issue 4, Oct. Dec. 2004, pp. 64 74. 95. S Kalasapur M Kumar and B. Shirazi, Evaluating service oriented architectures (SOA) fourth Annual IEEE International Conference on Pervasive Computing and Communications (PerCom 2006) March 2006, pp. 10 19. 96. S. R. Ponnekanti, B. Le e, A. Fox, P. Hanrahan and T. Wi nograd, ICrafter: A Service Lecture Notes in Computer Science, vol. 2201, 2001, pp. 56 74.

PAGE 161

161 BIOGRAPHICAL SKETCH Hen I Yang received his bac s degree in power mechanical engineering from National Tsing Hua University in HsinChu, Taiwan He pursued further studies in computer science and electrical engineering a nformation n etworking from Carnegie Mellon University in Pittsburgh, United States. His research i nterests focus on the system safety and reliability, programming models, and the system and middleware support for pervasive and mobile computing.

xml version 1.0 encoding UTF-8
REPORT xmlns http:www.fcla.edudlsmddaitss xmlns:xsi http:www.w3.org2001XMLSchema-instance xsi:schemaLocation http:www.fcla.edudlsmddaitssdaitssReport.xsd