Sub-System Details
We are continually creating, integrating, and testing new sub-systems, sensors, and interfaces in AlarmNet. Descriptions and pictures of the various sub-systems within the network follow.
Bed Network
Figure 2: MARC bed sub-system.
Figure 1: Bed sensor processing.
This sensor has been implemented at the MARC and is currently under integration and extension in our encompassing system.
The bed sensor is based on a air-pressure strip which measures the heart rate (low/high/normal), the breathing rate (abnormal/normal) and four levels of movement. The strip is located on the bed and is in contact with a person's trunk when the person lies on the bed.
A gait monitor is used to detect when the patient leaves or enters the bed. This sensor also detects five levels of gait (impact and a combination between fast/slow and near/far). It is located on the floor by the bed, and can detect falls when the residente exits the bed.
A motion sensor detects movement during the night, to aid in quantifying restlessness, a measure of sleep disturbance.
Interfacing with the primary sensor processing circuitry, a MicaZ mote connects to the wireless sensor network.
Motion Sensors
Figure 3: Motion-mote.
We have adapted a low-cost sensor module that is capable of detecting motion and light intensity changes. The module also has a simple one-button and one-LED user interface for testing and diagnostics. The module is interfaced to a MicaZ type wireless sensor node that processes the sensor data and forwards the information to the rest of the wireless network.
Figure 3 shows a MicaZ detached from its normal battery-pack and interfaced to the motion sensor via the 51-pin connector.
A set of such modules is used to track human presence and to monitor the lighting conditions in various locations of the living space. These activity data are used to maintain location context, and are fed to the back-end Circadian rhythm analysis software.
You can read details about the hardware design, including a circuit schematic. X-10 RF circuits were removed, making this a truly low-power sensor.
Body Network
We have implemented a wearable body network with MicaZ motes embedded in a jacket, which can record human activities and location using a 2-axis accelerometer and GPS. The components are shown (sans jacket) in Figure 6. The recorded activity data is uploaded subsequently through an access point for archival, from which past human activities and locations can be reconstructed.
In our work we have identified architectural requirements posed by such an application for interfacing with our system, and developed an architectural framework to accommodate it. We implemented a prototype of the application on MicaZ motes. Our experience with this preliminary prototype quantifies the effect of resource limitations when using a WSN on humans to record various activities. These include harsh memory constraints (for data recording purposes), bandwidth constraints which come into the forefront due to the high sampling rate requirements of these applications, and energy issues for longer battery life.
Figure 4: Pulse-Oximeter (Harvard design).
Figure 5: EKG, Pulse-Oximeter, and bed network.
Figure 6: Wearable body network for activity classification.
One mote is placed on the back so that the y-axis (either positive or negative) is always pointing downward. It may also possess GPS capability if the tracking aspect is to be used. The other two motes are placed one on each arm so that when the arm is in a vertical position pointing down, the y-axis (either positive or negative) also points down.
Figure 7: Bluetooth/Solar sensor board.
A web-server interface has also been implemented to make some SQL requests of a DBMS through a localized user interface which is a user view for this sub-system. This module allows the user to query the data collected and identify various activities that the user performed in the past and his or her location information of the past.
Other systems we have implemented and are extending are Telos-based Harvard designs. An EKG and pulse-oximeter (Figures 4 and 5) are wearable sensors. These are queryable using a graphical interface described below for the PDA.
We have developed SolarDust, a sensor board for Mica motes shown in Figure 7. It provides the mote's microprocessor with a UART interface to a bluetooth transceiver. This enables a body network to communicate with other commercially available sensor devices, as well as communicate with a resident's cell phone for emergency response.
Figure 8: Sampling of hardware supported by AlarmNet.
Other sensors and interfaced hardware supported by AlarmNet is shown in Figure 8.
Human Interfaces
Interfaces with residents, healthcare providers, and technicians have different requirements. Each must present an appropriate interface for performing the intended tasks, while conforming to the constraints imposed by form factor and usability.
Graphical interfaces for PDAs or Tablet PCs present high-level query interfaces for nurses, doctors, or other caregivers. They connect using 802.11b to the backbone infrastructure, where they gain access to the sensor network. These interfaces graphically present requested data for clear consumption by its user. The GUI we developed for real-time querying of sensor data is shown in Figure 9. A tracking GUI that queries in-network sensors is shown in figure 10. They run in a JVM on an HP iPAQ 5550.
Figure 12: Frequency analyzer app.
Figure 11: Wearable SeeMote with SeeQuery app.
Figure 10: Resident tracking GUI.
Figure 9: Real-time PDA Interface.
We have designed an LCD interface board for the MicaZ that is suitable for wearable applications, called the SeeMote. It presents sensor readings, reminders and queries, and can accept rudimentary input from the wearer. It has a five-button interface and a Secure Digital flash memory expansion port. Figure 11 shows the SeeMote's color LCD, running the SeeQuery application for querying and graphing sensor data. In Figure 12, the SeeMote is running a frequency analyzer application to aid in 802.15.4 channel selection. More details of its design are available.
Longitudinal and offline analysis, and technical system monitoring may be accomplished using conventional PC interfaces. Limited access may also be provided through this means to residents for self-monitoring.
Database and Data Mining
A MySQL database serves as a backend data store for the entire system. It is located in a PC connected to the backbone of the system. It stores all the information coming from the infrastructure for longitudinal studies and offline analysis.
Circadian Activity Rhythms
We have developed a pattern mining and analysis program for the CAR called SAMCAD (software for automatic measurement of circadian activity deviation) that measures the rhythmic behavioral activity of patients and detects any behavioral changes within these patterns. The CAR algorithm embedded in SAMCAD is statistical and predictive. As applied to motion sensors, it enables us to continuously track resident movements, and to learn his/her life habits (presence-based CAR) and vivacity (activity-level based CAR).
Figure 13: Circadian Activity Rhythm GUI.
These presence and activity-level based CAR are respectively based on the distribution of the probability of user presence and the average number of motion events per room. CAR runs on the back-end of the system on a PC, and polls a database where patient activity is stored. CAR supports a GUI, shown in Figure 13, which displays various information related to the activity analysis, such as the number of abnormal time periods (under-presence or over-presence) or abnormal activity (hypo- or hyper-activity) that occurred per hour, room and day during day or night, and the length and dates of the stay of the resident.
Other graphs of the GUI display the main results of the CAR analysis. Data shown in Figure 13 is from presence-based CAR in a real clinical case study for a healthy resident who stayed 25 days in an assisted-living facility. The first graph on the left displays the average time the user spends in every room each hour, calculated over the number of days of the stay of the resident. The second graph, on the right, indicates that after 18 days the presence based CAR for this patient has been learned. These graphs can provide a wealth of information about activity patterns such as the sleep/wake cycle, or some medical hints to the physician about some activities of daily living (ADLs) of the resident such as eating, hygiene and sleeping.
To use CAR for health monitoring, after the learning period, any statistically significant anomalies that are detected will alert physicians who can investigate the source of the trouble (sleep/wake period longer, one meal less, etc.) by focusing on the region of the anomaly as identified by CAR. The hypothesis is that behavioral changes could, in the long-term, reveal health decline or pathologies. This hypothesis was clinically validated in collaboration with the medical research group MARC (Medical Automation Research Center) at UVA. To validate this hypothesis, clinical behavioral patterns of older adults in assisted-living facilities were extracted from real data sets, and behavioral changes were studied by consulting the medical notebooks of the caregivers in charge of the monitored residents. See (VG03, VND02, and VAD+06) for details about the construction of the CAR (modeling) and clinical validation.