Meditrina: Addressing the System-level Challenges to Ambient Assisted Living Albert F Harris III†, Rob Kooper+ , Robin Kravets†,1 , Gaia Maselli∗,2 , and Chiara Petrioli∗,2 † Department of Computer Science, University of Illinois at Urbana–Champaign National Center for Supercomputing Applications, University of Illinois at Urbana-Champaign ∗ Department of Computer Science, University of Rome “La Sapienza” INTRODUCTION As the world’s population ages, there is a driving need to provide technology-enabled assisted living solutions to help manage the comfort and lives of the elderly [1, 2, 3, 4]. Similar support is desirable for the disabled and ill who require extensive assistance. Using technology to augment the lives of individuals with the need for assistance in dayto-day activities is a natural idea; however, assisted living scenarios have a unique set of requirements that make the straight-forward application of current state-of-the-art technology very challenging. Essentially, assisted living systems must monitor, control, and interact with a number of different components of the living environment, from various medical devices, to environmental controls, to the people themselves, without interfering with the lives of those being monitored. The goal from a systems perspective is to support intelligent applications that augment the ability of the limited number of caretakers to effectively and efficiently maintain the health and comfort of user while minimizing intrusive behavior. Additionally, the complexity of the underlying systems and management of the diverse devices must be hidden to enable easy-to-use interfaces and easy-to-design applications. These requirements drive the need for new system architectures to manage the entire assisted living environment. If we look at the system from the bottom up, the complexity of providing the needed services stems from the heterogeneous nature of the devices and communication technologies used to interact with those devices. Additionally, such a complex system must be designed in a distributed manner to support efficient resource usage and fault tolerance. A pplication A ctivity M anager M editrina 1. IntelligentControlSystem Categories and Subject Descriptors: D.4.4 [Communications Management]: Network communication General Terms: Management, Design Keywords: Ambient healthcare, device management U serControl System kooper@ncsa.uiuc.edu, {maselli,petrioli}@di.uniroma1.it A utom ated ControlSystem {aharris,rhk}@cs.uiuc.edu, Caregiver ControlSystem + TaskHMygea anager Service M anager PhysicalD evices PhysicalD evices PhysicalD evices PhysicalD evices Figure 1: System architecture An effective system must enable information collection and device actuation while not exposing the complexity of the system to either the applications or the users. However, the ultimate goal of such a system is to provide the support required by the applications and users. Therefore, the key to a successful system lies in the design of the interfaces to the applications, the environment and the users. The main contribution of this paper is the design of an architecture, called Meditrina, that can be used to facilitate an assisted living solution in an effective and efficient manner. 2. MEDITRINA In the design of Meditrina, our ambient assisted living architecture, we assume that a number of components are present in the system (see Figure 1). The highest level component, the application, implements the functionality of the assisted living environment. At the lowest level, there is a collection of physical devices, including sensors, network devices, home appliances, and medical devices. Finally, there is a control plane, which we call the Intelligent Control System, which facilitates ongoing user activities by providing rules and guidelines within which environmental decisions can be made (e.g., giving safe thresholds for water temperature to be used in a bath). The intelligent control system is the source of rules that govern actions within the ambient assisted living environment. For each activity, it specifies the action to be taken according to physicians advice and the user’s desires based 1 The work was partially performed when visiting the CS Department, University of Rome ”La Sapienza” 2 The work was partially funded by the Eureka ITEA project AmIE (Ambient Intelligence for the Elderly) Copyright is held by the author/owner(s). HealthNet’07, June 11, 2007, San Juan, Puerto Rico, USA. ACM 978-1-59593-767-4/07/0006. 79 H ygea A ctivity Rules U ser/A ctivity Param eters Thresholds Task List Task Thresholds A ctivity N otification A nom alies Task Results Task Library Service Q uery Task D ata Task Status Task Status M onitors Regulators N otifiers Sensors A ctuators Service D iscovery A ctivity M anager Task M anager Service M anager aided by the Meditrina system, which takes inputs from the intelligent control system, senses, and reacts according to current user behavior and state. The interaction of the system with the user makes the system adaptive, allowing for flexibility, since the system may be personalized to a specific user in the course of activities (e.g., choosing a shower-water temperature). The Meditrina architecture contains three main components, reflecting this decomposition of activities (see Figure 2). The first component is the Activity Manager, whose job is managing activities for users. The second component is called the Task Manager, whose job is to manage specific tasks needed to accomplish activities within the system. The third component, called the Service Manager, consists of the interfaces, called service coordinators, to the ambient devices providing services in the environment, including user devices (e.g., PDAs), environmental sensors (e.g., light sensors), medical devices (e.g., heart rate monitors), environmental actuators (e.g., thermostats), and networked, computer-equipped household devices (e.g., ovens). In addition to these three components, there is a Service Discovery component, which enables optimizations related to choosing devices within the system to perform tasks. In the following subsections, we present descriptions of each of the components of the architecture. M editrina Service response Figure 2: Meditrina architecture on the parameters that characterize and personalize the activity for each user. Violations of these rules are automatically controlled by the system whenever possible: for example, a rule for a user’s bath may be that the temperature must be below X, within Y degrees. If the user increases the amount of cold water to the point that the temperature goes below Y degrees, the system automatically increases the flow of hot water to reach the dictated temperature. The intelligent control system includes three types of control interfaces to support users with different skill levels and specialties (see Figure 1). The caregiver control system is the subsystem that allows caregivers to oversee the operation of the entire system and handle any anomalies that arise. Such oversight is needed in life-critical systems, and allows a group of physicians to send commands to the system, or send assistance (e.g., an ambulance) directly to users in the case of emergencies. The automated control system contains predefined rules to augment system functionality. The user control system allows input from the users to help adjust their own comfort level. Essentially, the combination of these components of the intelligent control system provide two different types of assistance. The caregiver control system and the user control system are reactive, always working in response to some emergency, anomaly, or user’s wish. On the other hand, the automated control system is proactively attempting to avoid complications. The Meditrina architecture provides communication support between the devices, applications, and intelligent control system, while allowing optimizations at the system level to save energy, match sensor reading accuracy to application needs, and improve the lifestyles of the users while offloading management from the caretakers to the system. We call the goal of a specific application an activity. Activities are decomposed into tasks required to reach a successful conclusion. Finally, each task requires some number of services from the ambient assisted living environment. The idea behind our architecture is that everyday routine is modeled as a set of activities that follow and possibly interlace with one another. Examples of activities are sleeping, having breakfast, taking a bath, taking medicine, measuring vital signs, and leaving home. The interleaving of activities is caused by normal user behavior (e.g., a user may need to take medicine during breakfast, causing the suspension of the breakfast activity until the medication activity is complete). During their daily routine, the user is monitored and 2.1 Activity Manager The activity manager is responsible for managing user activities, by decomposing each activity into a number of tasks, and propagating them along with any parameters from the intelligent control system to the task manager. The upper interface interacts with the intelligent control system to prevent anomalous user behavior that may have negative effects. For example, while taking a bath, several factors in the environment must be monitored and controlled (e.g., regulating air temperature, regulating water temperature, and closing windows), so that the user activity can be performed according to the rules specified by the intelligent control system (e.g., water temperature must fall within a specific range), but the user can choose their preferred water temperature, within that range. The intelligent control system also comes into play in case of emergency, or unusual behavior, and reactively provides support according to the specific situation. In these situations, the activity manager interacts directly with the control system, passing it the values that define the anomaly. The control system can in turn issues specific queries to the activity manager to better understand the situation (e.g., requesting some vital parameters) and enter commands that specify the action to be taken. 2.2 Task Manager The task manager is invoked by the activity manager for each part of an activity. Consider the previous example of taking a bath, this single activity is broken into regulating air temperature, regulating water temperature and pressure, and monitoring user vital signs. Each of these tasks is handled by a manager that is in charge of guaranteeing efficient task execution. Specifically, task managers are responsible for finding available services from the service discovery component, making specific service requests to the service manager, and monitoring task performance. The optimization of network costs is performed by the 80 or the user according to application requirements. Their task is to output sensed data, in a number of formats including: boolean, numerical, complex (e.g., images), or streaming (e.g., video). A sensor can either be queried, triggered, read, or set to continuously sense on some pre-defined timescale: the former is called reactive sensing, the latter proactive sensing. Sensors have different levels of complexity: some capable of sensing only a single property, others capable of sensing multiple properties (e.g., heat and light). Actuators - Active components that change the physical environment. Specifically, actuators activate devices to change the state of the environment (e.g., generating sounds, adjusting light levels, changing the ambient air temperature, or locking a door). Both types of devices export information about their functions to upper layers. In the case of sensors, such data includes what factors in the environment they sense, their accuracy, and the frequency with which they take readings. For actuators, such data includes the costs of performing actions, the expected time frame for a result to be reached, and the probability with which expected changes occur. This data can be used by task manager, along with information from the intelligent control system to choose which sensors and actuators to use for particular activities. task manager that takes as input the application requirements from the activity manager and the cost and reliability for each service offered by the devices from the service manager. The objective of the task manager is to trade off application requirements and network costs, so as to achieve a satisfying quality of service, keeping network cost as low as possible. This kind of optimization is performed at the task level because the same task may be performed by using different sensors and actuators, with different costs and quality. The task manager is located between the activity and service managers to get application requirements from the former and network costs from the latter. The task managers interface with the activity managers to report on the results of the tasks making up the activity. The task manager also interfaces directly with the service manager to monitor and perform their tasks. 2.3 Service Manager The Meditrina architecture provides a service manager that defines three types of service coordinators, through which other system components interact with the various devices in the environment. Each service coordinator provides a clean interface to one or more devices for use by task managers. There are two classes of service coordinators to support the various types of devices in the ambient environment, passive and active. Passive components, which we call monitors, sense and output collected data. Active components include both sensing and acting. Within this class, we define two different components: regulators and notifiers. The formers adjust environmental conditions, while the latter notifies the users to take certain actions. Monitor - A passive component that collects sensed data. Monitors can watch users’ vital signs (e.g., heart rate or blood pressure), or environmental conditions (e.g., light levels, air temperature, or humidity). Monitors are passive in the sense that they do not perform any action, but just sense and report data. Regulator - An active component that involves both sensing and modifying environmental conditions. Regulators are based on the paradigm “sense and adjust,” since they adjust the environmental state according to application requirements. Examples of regulators are: water temperature regulators, water pressure regulators, and door openers. Thus a regulator coordinates sensors and actuators according to a target task. Regulators may have cyclic properties: after triggering an actuator to adjust the environment, the regulator must return to monitoring to ensure the desired effect was achieved. Notifier - An active component that uses notifications to encourage specific actions in users (e.g., taking medication). Notifiers are based on the paradigm “notify and wait for response,” and involve the interaction of sensors, actuators, and user feedback. After notifying the user, the notifier waits for a response, checks if the task has been correctly performed, and potentially takes further action. These service coordinators provide the interfaces to devices in the system, which can be divided into two types: sensors and actuators. Sensors are passive components, merely taking input from the environment. Actuators are active components, affecting factors within the environment (e.g., activating the compressor on the air conditioning unit). Sensors - Passive components that sense the environment 3. FUTURE DIRECTIONS We have assembled a large number of devices, both sensors and actuators, to create an initial testbed. We plan on deploying the initial implementation of the Meditrina system on this testbed in the near future. Once we have the initial deployment of the system, we can start to experiment with various optimizations of this system in all layers. The nature of these optimizations depend greatly on the application needs; however, there are general techniques that can be applied. In terms of service discovery, we are analyzing techniques to perform rapid, cheap (in terms of computation, storage, and energy) device and service location. This is complex because not only are the services in the area unknown to new users, the available means of communication are also unknown. Once available communication channels are discovered, the problem of optimizing the communication by choosing one or more channels arises. Finally, optimizing the choice of devices to serve a particular application’s needs over the space of available devices and communication channels, while taking into account the accuracy and other properties of the devices’ abilities is a complex problem that we are beginning to model. 4. REFERENCES [1] Q. Wang, W. Shin, X. Lui, Z. Zeng, C. Oh, B. Alshebli, M. Caccamo, C. Gunter, E. Gunter, J. Hou, K. Karahalios, and L. Sha, “I-Living: An Open System Architecture for Assisted Living,” in IEEE SMC, 2006. [2] D. Malan, T. Fulford-Jones, M. Welsh, and S. Moulton, “CodeBlue: An ad hoc sensor network infrastructure for emergency medical care,” in International Workshop on Wearable and Implantable Body Sensor Networks, 2004. [3] I. Mohomed, M. Ebling, W. Jerome, and A. Misra, “HARMONI: Client middleware for long-term, continous, remote health monitoring,” in UbiHealth, 2006. [4] W. Heinzelman, A. Murphy, H. Carvalho, and M. Perillo, “Middleware to support sensor network applications,” IEEE Transactions on Network, vol. 18, no. 1, pp. 6–14, January-February 2004. 81 View publication stats