1. A 3D SIMULATION FRAMEWORK FOR
SAFE AMBIENT-ASSISTED HOME CARE
Christophe Soares
Co-Authors:
Carlos Velasquez, Rui Moreira, Ricardo Morla, Pedro Sobral and José Torres
INESC-Porto ISUS
FEUP, University of Porto FCT, University Fernando Pessoa

2. Introduction
Goals
Research Area
Safe Home Care Architecture
Simulation Structure
Feature Interaction Workflow
Conclusion

3. INTRODUCTION
•Statistics show aging trend in the world population
•Growing need for automated health care support
for the sick and elderly at home

4. INTRODUCTION
•Reduce overall cost of the health care systems
•Promote more comfort and safety at home
•Ambient Assisted Living emphasis (cf. MATCH, eCAALYX)

5. VIDEO

8. GOALS
•Support safe deployment and reconfiguration of
home health care smart spaces
•Automatically adapt system interface for elderly
people
•Provide non-intr usive patients remote
monitoring and assistance

9. RESEARCH AREA
Smart spaces:
•sensors,
•actuators,
•computation devices,
•and communication-rich appliances.

10. RESEARCH AREA
‣ New appliance can interfere with the appliances that
already exist in that space
‣ For home health care is critical to prevent interference
occurrence

11. RESEARCH AREA
Feature Interaction - Interference
•Independently deployed OTS systems may interact
unexpectedly resulting misbehaviors or malfunctions

12. RESEARCH AREA
Reflection - Distributed Systems
•An architectural pattern to organizes software systems
into base-level and meta-level

13. RESEARCH AREA
Support simulation to generate synthetic data:
•identify a priori interference,
•pre-deployment feature interaction detection,
•handling of interferences in Real Time between
different appliances (cf. system’s malfunctions).

14. SAFE HOME CARE
ARCHITECTURE
Reflective Middleware Meta Level
Simulation Framework
Feature Interaction Engine
Base Level
Sensors / Actuators
OTS Applications API
SHC System GUI

15. SIMULATION
‣ Full Simulation
‣ Systems act autonomously based on their
behavior (deterministic reactions)
‣ Semi Simulation
‣ A human may control the avatar to generate ad
hoc interactions (stochastic reactions)

16. SIMULATION STRUCTURE

17. SAFE HOME CARE
ARCHITECTURE
Reflective Middleware Meta Level
Simulation Framework
Feature Interaction Engine
Base Level
Sensors / Actuators
OTS Applications API
SHC System GUI

18. FEATURE INTERACTION
WORKFLOW
SHC 3D read existing
Meta-model states from
Simulation database
Scenario create the GoOS
Outcomes graph using Table
Classification
Case
Matching
Table Case prune the GoOS
using GoES
Pruning sequences
GoES
Reasoning
No Feature Feature
interaction interaction

19. SIMULATION
OpenSim used as simulation framework:
• generate off-the-shelf (OTS) state interactions in
the smart-space.
• data used to test collected feature interactions
between OTS systems.

20. CLASSIFICATION
Outcome 1 Outcome 2
alarm ringing alarm ringing
Graph Representations are well ringing ringing
take_ pill take_ pill
understood and provide a
flexible representation for needs_ pill notify needs_ pill notify
state sequence transitions. call _ in alarm call _ in alarm
ringing buzzer ringing buzzer
During system runtime or
receives_call call receives_call call
simulation a graph is built by
capturing the actual state history call medicated call
of all elements: Graph of take_call take_call
Observed States (GoOS).

21. PRUNING
Knowledge:
- expected behavior of each application is captured
into a state transition graph
- assemble a unique graph with common start and
finish nodes: Graph of Expected States (GoES)

22. PRUNING
start
Drug Phone Person
Knowledge:
Dispenser
call _ in
alarm needs _ pill receives _ call
- expecteddrug low _battery upside_ down
low _
behavior of each application is captured
ringing
buzzer
into a state transition graph
call call _ in
take _ pill take _ pill
notify
- assemble a unique graph ringing common start and
with
medicated take_ call
finish nodes: Graph of Expected States (GoES)
alarm
buzzer call
finish

23. REASONING
Outcome 1 Outcome 2
alarm ringing alarm ringing
Outcome 1: ringing take_ pill ringing take_ pill
• empty set, needs_ pill
Result 1
notify
Result 2
needs_ pill notify
• all systems react as expected, needs_ pill
• no feature interaction exists.
call _ in alarm call _ in alarm
ringing buzzer ringing buzzer
receives_call call receives_call call
Outcome 2:
call medicated call
• not empty, take_call take_call
• “need_pill” has not been pruned,
identify a misbehavior

24. REASONING
Outcome 1:
• empty set, Result 1 Result 2
• all systems react as expected, needs_ pill
• no feature interaction exists.
Outcome 2:
• not empty,
• “need_pill” has not been pruned,
identify a misbehavior

25. CONCLUSIONS
We applied this approach through different simulated scenarios
with several OTS systems involved.

26. CONCLUSIONS
This evaluation allowed us to:
•define and explore the state-graph representations to perceive
feature interaction
•evaluate the pertinence and accuracy of applied techniques on
different home care use cases
•explore the representation and simulation models through 3D
virtual worlds

27. CONCLUSIONS
We are currently working on extending our approach to
support inter-system Feature Interaction detection and
resolution.

28. QUESTIONS ?
CSOARES@UFP.EDU.PT