I-Living: An Open System Architecture for Assisted Living

Download Report

Transcript I-Living: An Open System Architecture for Assisted Living

I-Living: An Open System
Architecture for Assisted Living
Qixin Wang, Wook Shin, Xue Liu, Zheng Zeng, Cham Oh,
Bedoor K. AlShebli, Marco Caccamo, Carl A. Gunter, Elsa
Gunter, Jennifer Hou, Karrie Karahalios, and Lui Sha
Presented in IEEE SMC 2006
Oct. 2006
Motivation
• The aging of baby boomers has become a social and
economic challenge
– Population:
• In USA alone, population over age 65 is expected to hit 70 million
by 2030, doubling from 35 million in 2000, and similar increases
are expected worldwide (MIT’s TECHNOLOGY REVIEW
July/August 003).
– Expenditure:
• Expenditure for health-care projected to rise to 15.9% of the GDP
($2.6 trillion) by 2010 (Digital 4Sight’s Health Care Industry
Study).
– Unless the cost of senior care can be significantly reduced
by technological means, it could bankrupt the already
shaky social security and medicare systems.
Motivation
• Move-away from the nuclear family household and
the increasingly youth-oriented society
– Leaves many people to their own means in receiving health
care and satisfaction from life.
– Only 10% of elderly people of age 65-85 and 25% of those
of age 85 and above in the USA are institutionalized
(National Institute of Aging).
– Numbers of elderly people living alone in Korea has
increased 100% in the last ten years.
– Many suffer from deteriorating sensing and interacting
capabilities, such as memory, eye sight, hearing, dexterity
and mobility.
– Many suffer from chronic diseases
Design Goals
• Dependability:
– Critical Services will be failure safe
– High availability
– Robustness
• Low Cost and Flexibility
– Open to low-cost third-party devices
– Assumption, protocol, QoS guarantee discrepancies are to be
discovered by machine checkable means
• Security and Privacy
– Different levels of info disclosure to different roles
– Authentication, Encryption, and Anti-DOS (Denial-Of-Service)
• QoS Provisioning
– Timing, reliability, criticality guarantees
– Over wireless and wireline
Design Goals
• Wireless Interference Mitigation
– Bluetooth v.s. IEEE 802.11b
– IEEE 802.11a v.s. Microwave
– QoS guarantee under wireless interference
• Human Computer Interfaces
–
–
–
–
Lightweight
Easy-to-Use
Safe and Robust to user mistakes
Provide different control levels of info disclosure
Design Goals
• Thorough Evaluation and User Group Studies
– Evaluated in terms of
• the extent to which the technology help elderly people
with their independent living in the home or assisted
living facilities
• their attitudes toward deploying these technologies
– Different hypothesis amenable to theoreticallygrounded tests will be established
– Detailed comprehensive evaluation carried out by
professionals in real facilities (WUSTL)
Example Scenarios
•
•
•
•
•
Activity Reminder
Vital Sign Measurement
Personal Belonging Localization
Personal Behavior Profiling
Emergency Detection
I-Living System Architecture Design
(Gateway Mode)
•
Assited Person
(AP)’s Home
covered by
Wireless LAN
(WLAN)
•
Gateway Router
connects AP home
WLAN to the
Internet
•
Assisted Living
Hub (ALH)
manages dumb
devices through
peripheral network
(e.g. Bluetooth)
I-Living System Architecture Design
(Gateway Mode)
•
ALH and Smart
Devices can connect
to Internet via
Gateway Router
•
Assisted Living
Service Provider
(ALSP) Server
database is the
central database
where all data is
stored (vital sign,
reminder, personnel
information, role
access policy, logs,
etc.)
I-Living System Architecture Design
(Gateway Mode)
•
Clients of ALSP
Server include:
Caregiver,
Clinician,
Designated
Relatives of the
AP, and the AP
him/herself
I-Living System Architecture Design
(Cellphone Mode)
•
In case of the
Gateway Router
failure, A
Bluetooth
Cellphone can
dial up as a
cellphone
modem
•
ALH and Smart
Device associate
with the
cellphone
modem through
bluetooth
network
I-Living System Architecture Design
(Cellphone Mode)
•
This also allows
assisted-living
service when
the AP is out-ofhome
System Architecture Design of
Assisted-Living-Hub (ALH)
•
Device Monitoring
Daemons: Detecting
the join and leave of
various assisted
living devices (e.g.
Bluetooth oximeter,
Bluetooth scale,
ZigBee
accelerometers etc.)
•
Device Registry
Service: Local
database on what
devices are available,
and the proxy objects
to access the
corresponding
devices.
System Architecture Design of
Assisted-Living-Hub (ALH)
•
Unified ApplicationPeripheral
Communication
APIs: Encapsulates
the underlying
networking APIs
(e.g. Bluetooth,
Conventional
Internet, ZigBee,
Infrared) to a unified
networking API.
System Architecture Design of
Assisted-Living-Hub (ALH)
•
Other Java APIs from
J2ME/J2SE: J2ME
shall be provided if the
ALH is a PDA; J2SE
is provided if the ALH
is a PC
•
Internet Heartbeat
Daemon: Checking
whether the Gateway
Router is alive. In case
of Gateway Router
failure/recovery, it
shall be in charge of
activating/deactivating
the Bluetooth
Cellphone Modem
System Architecture Design of
Assisted-Living-Hub (ALH)
•
ALH Main Deamon:
Activating/Deactivati
ng specific assisted
living applications
(e.g. taking oximeter
readings, reminding)
Security and Privacy Mechanisms
• To protect information confidentiality
(different visibility to different roles)
– Partial Encryption:
• e.g. first encrypt the vital sign reading using the key
between AP and clinician; then encrypt the whole
message (with administrative info) using the key known
to AP, ALSP Server and the clinician. Therefore,
although the message is stored in ALSP Server, but
ALSP Server cannot read the vital sign.
Security and Privacy Mechanisms
• To ensure data integrity in the home WLAN
with link-level authentication and encryption
– Wi-Fi Protected Access 2 Personal (WPA-PSK)
• Propose using specialized USB memory stick
to deliver encryption keys
Current Demo Implementation
(Reminder)
1. Clinician input the
reminder schedule:
e.g. Take oximeter
readings twice a
day for one month
2. The reminders are
saved in ALSP
Server database as
an XML
3. The reminder
application in ALH
polls the reminder
XML, and reminds
when it is time.
Current Demo Implementation (Vital
Sign Reading)
1. Bluetooth Device
Monitoring Daemon
discovers the Bluetooth
Oximeter (once it is
turned on)
2. Oximeter Reading
Application on ALH
reads the oximeter and
upload the reading into
ALSP Server database
3. Clinician browses the
oximeter reading history
at his office.
Related Work
• Center for Future Health (CFH), University of
Rochester
– Key component: visual system for object
recognition and tracking
– Our research complements CFH in two aspects
• Focus on assisted living environment; CFH is for
nursing homes and hospitals
• Focus on open software architecture
• None-intrusive sensing instead of visual system
Related Work
• Aware Home, Georgia Tech
– Focuses on context awareness
– Ours focus on QoS provisioning, wireless
networking, security and privacy, HCI
• Smart In-Home Monitoring System,
University of Virginia
– Focus on non-intrusive data collection
– The data management system is complementary to
our research.
Related Work
• Age-in-Place Advanced Smart-Home System, Intel
– Help elderly people with Alzheimer’s diseases
– The focus is not on systems reliability, robustness, security,
and wireless coexistance.
• To our best knowledge, we are the first to
– advocate an open environment that allows devices from
different vendors to co-exist and collaborate
– Working with experienced medical and health care experts
at Washing University in Saint Louis in employing a
comprehensive, systematic HCI-based methodology for
evaluation among real-world elderly people.
Conclusion
• Openess and Flexibility is provided by deploying
Device Registry Service, Proxy, Unified ApplicationPeripheral Communication APIs, XML and Java
technology.
• Availability is ensured by enabling system to operate
both in the Gateway Mode and Cellphone Mode.
• Security and Privacy are addressed partial encryption,
WPA2-PSK
• Implemented 2 demo applications for proof-ofconcept
Thank You!