documentation overviewstatic.sws.bfh.ch/download/mt-10-01-14-doc.pdf · documentation overview...

T-213-10 / V 1 EMS_Doc_Overview-v1.0.doc

of 2

Compare with the valid version before usage of printed documents!

Process:

Documentation Overview

Project: Proof of Concept Study „Elderly Monitoring System“ for the uMove Framework

Number MT-10-01.14

Version: 1.0

Replace document: n/a (first edition)

Template:

Number MT-10-01.14 Class MAS-IT 10-01 Student René Süssmilch,

[email protected], +41 (0) 79 475 85 72 Advisor Pascal Bruegger, PAI Group,

[email protected] +41 (0) 26 300 87 63 Expert Reto Koenig, Software Schule Schweiz, Wankdorffeldstrasse 102

Postfach 325, CH-3000 Bern 22, [email protected], +41 31 84 83 272 Keywords uMove, Elderly person, monitoring, KUI, kinetic user interface

Release

Role Name Title Date / Signature

Author: Süssmilch René Student

Documentation Overview Version 1.0

T-213-01 / V 1 EMS_Doc_Overview-v1.0.doc

of 2

��ABC��B�D�EE�F��C��B��FB�B��B�B��B��

1 User requirements specification

2 Software requirement specification

3 Software description

4 Testi instructions and report

5 Project summary

Description of the student’s tasks.

Title : Elder Monitoring System (EMS)

1. General framework This project is part of PhD project (uMove: Interaction through motion in Ubiquitous Computing) of the university of Fribourg. The main goals are to develop the concept of Kinetic User Interface (KUI) and uMove middleware which allows programmers to develop applications where mobile entities (living things, objects) interacting with their environment are observed under different points of view. The “world” of entities represents a system (systemic approach) and is managed by uMove. The applications connected to uMove get the necessary information about the entities their observer. The observers (software components) analyse the situation of entities taking into consideration their activities and contexts provided by physical sensors (e.g. motion, temperature, location, heart beat) and triggers events to the application according to pre-defined rules used to detect dangers or critical situations for instance. uMove offers a Java programming environment to easily create entities, observers, viewer, sensors and to plug specific applications without worrying about objects inter-communication and update, location changes. 2. Tasks to be done. The tasks described under are the expected work to be done by the student and will the criteria for the evaluation of the master project. 2.1 General scenario: The EMS project focuses on an application which monitors elders or impaired people living alone or in a nursing home. The goal is to allow medical staff to be alerted any time a monitored person needs special attention or is in a critical situation. The application will inform the contextually more appropriate person (nurses, doctors, …) according the given situation of the patient. The monitored person will carry a mobile device with specific sensors such as accelerometer, gps, indoor location technology, heart frequency meter, blood pressure. The medical staff will also carry a mobile device with an application able to get messages from the server application, to be located (indoor or outdoor) and to analyse its current activity in order to be contacted or not in case of needs. The applications will be developed in Java (SE for server and Android for mobile devices). Lists of tasks: The project contains two parts:

1. the server-based application 2. the mobile application

2.2 The server-based application It monitors the physical environment (city) and the building (nursing home) and reports the state (motion, location, eventually physiological information) of the elders. The goal is to allow nurses to easily get information on the screen about the population of the home. 2.2.1 Expected features:

- The application must implement a KUI system using the uMove library. - The student will setup an indoor location-sensor based on Bluetooth technology and uses the

GPS coordinates to locate the monitored person when outside the building.

- The application will provide a visualization of the situation with a GUI representing both the plan of the home (see fig. 1) and the tracking of the person outside (using google map for instance).

- A simple situation management must be implemented in order to detect critical situations of the monitored person and raise alarms on the screen.

2.3 The mobile applications There will be two mobile applications: The first one concerns the monitored person and processes the motion, location and manages the user feedback. For instance, if the person does something not allowed, he/she will receive a warning on its smart phone. The second application will be for the nurses and provides information or alarm to the medical staff if an intervention is required. Each monitored person and medical staff will carry a smart phone running Android and the mobile version of uMove. The mobile application will communicate with the server-based application and transmit the data from the enabled sensors (accelerometer, gps, …). The communication between the two uMove is provided. The student will focus on the processing of the information and the feed back to the monitored person and medical staff. 2.3.1 Expected features:

- The mobile applications must implement a KUI system using the uMove library. - The application for the elders processes sensor data from at least

o Accelerometer for basic motion detection (standing, moving, falling for instance) o GPS (for outdoor location tracking) o Bluetooth (for indoor location tracking) If possible or needed, other sensors can be used in order to increase the precision of the elder activity and situation.

- The application for elders must provide an adapted feedback to the user when a critical situation is detected.

- A simple situation management must be implemented in order to detect critical situations of the monitored person and raise alarms. For instance, if the person is located in an inappropriate location (too far or dangerous), the system should react and alarm both the server-based application and the responsible staff.

- The application for the medical staff must be able the locate and transmit the location and the

basic activity to the server-based application - It must also be able to receive alarms from the server-based application and manage the

appropriate feedback to the user (nurse or doctor). 2.4 uMove evaluation: It is also requested to include in the final report an evaluation of the uMove API (umove, coordination, monitoring and mobile monitoring JARs). The evaluation will contain the following points:

- Usability of uMove (programming point of view) - Problems and bugs encountered - Proposition of improvement.

2.5 Provided infrastructure. The student will receive a running version of uMove and Coordination allowing the communication between server-based and mobile application. He will also receive a running prototype of an application implementing a server-based user monitoring application (smart environment) with a GUI and the mobile application running on Android. It is connecting automatically to the smart environment when entering in the building and transmits the location and activity data to the server. This prototype has been developed for the master thesis of Benjamin Hardorn. The goal is to use this work and to extend it to a more concrete case study such as EMS. The student will receive the report describing the prototype. The student will also receive a training on uMove, the coordination JARs and the prototype. This will allow to directly focus on the EMS project without worrying about “low level” consideration. Contact : Pascal Bruegger, PAI Group, [email protected] Link : http://diuf.unifr.ch/pai/umove

Fig 1. General diagram of the EMS applications (server and mobile)

uMove

EMS app

sensors

Elder

Location, motion data

Alarms

Alarms, feedback

EMS server-based application

Intervention required

ICU Scandinavia www.icuscandinavia.com

T-213-01 / V 1 EMS_Software_Requirement_Specification-v1.0.doc

Page 1 of 22

Process:

Software Requirement Specification


Number MT-10-01.14

Version: 1.0


Template: T-213-01 Software Requirement Specification




Postfach 325, CH-3000 Bern 22, [email protected], +41 31 84 83 272 Keywords uMove, elder person, monitoring, KUI, kinetic user interface

Release



Review: Bruegger Pascal Advisor

Release: Koenig Reto Expert

Software Requirement Specification Version 1.0


Page 2 of 22

1 Introduction ......................................................................................................................... 4

1.1 Purpose ................................................................................................................................... 4

1.2 Scope ...................................................................................................................................... 4

1.3 Terms & Abbreviations ............................................................................................................ 5

1.4 References .............................................................................................................................. 6

1.5 Requirements Coding .............................................................................................................. 6

1.6 Priority ..................................................................................................................................... 6

2 Overall Description ............................................................................................................. 6

2.1 Product Perspective ................................................................................................................ 7

2.2 Product Functions ................................................................................................................... 7

2.3 User Characteristics ................................................................................................................ 8 2.3.1 Elder people ......................................................................................................................... 8 2.3.2 Medical staff ......................................................................................................................... 8 2.3.3 System administrator ........................................................................................................... 8

2.4 Constraints .............................................................................................................................. 8 2.4.1 Regulatory Limitation ........................................................................................................... 8 2.4.2 Safety and Security Considerations ..................................................................................... 8

2.5 Assumptions and Dependencies ............................................................................................. 8

2.6 Apportioning of Requirements ................................................................................................. 8

2.7 System requirements .............................................................................................................. 9 2.7.1 System interfaces ................................................................................................................ 9 2.7.2 User interface ....................................................................................................................... 9 2.7.3 Hardware Interface............................................................................................................... 9 2.7.4 Software interface ................................................................................................................ 9 2.7.5 Communication interface ................................................................................................... 10 2.7.6 Storage limitation ............................................................................................................... 10 2.7.7 Location specific requirements ........................................................................................... 10

3 Specific Software Requirements for server based application .................................... 11

3.1 General ................................................................................................................................. 11 3.1.1 Use Cases ......................................................................................................................... 12

3.2 Set up the system ................................................................................................................. 12

3.3 Check condition of elder person ............................................................................................ 13

3.4 Receive location .................................................................................................................... 14

3.5 Receive situation ................................................................................................................... 14

3.6 Appraise situation .................................................................................................................. 15

3.7 Alarm escalation .................................................................................................................... 15

3.8 Alarming medical staff ........................................................................................................... 16

3.9 Confirm alarm........................................................................................................................ 16

4 Specific Software Requirements for elder person mobile application ........................ 17

4.1 General ................................................................................................................................. 17 4.1.1 Use cases .......................................................................................................................... 18

4.2 Analyze of activity ................................................................................................................. 18

4.3 Check temperature ................................................................................................................ 18



Page 3 of 22

4.4 Check location ....................................................................................................................... 19

4.5 Send context changes ........................................................................................................... 19

4.6 Alarming ................................................................................................................................ 19

4.7 Usage of the mobile app ....................................................................................................... 19

5 Mobile application for medical staff requirements ........................................................ 20

5.1 General ................................................................................................................................. 20 5.1.1 Use Cases ......................................................................................................................... 20

5.2 Alarming ................................................................................................................................ 20

5.3 Confirm alarm........................................................................................................................ 21

5.4 Change situation ................................................................................................................... 21

5.5 Check location ....................................................................................................................... 21

5.6 Send context changes ........................................................................................................... 22

5.7 Usage of the mobile app ....................................................................................................... 22

6 Documentation .................................................................................................................. 22

7 Document history ............................................................................................................. 22



Page 4 of 22

1 Introduction

1.1 Purpose

The EMS project focuses on an application which monitors elder or impaired people living alone or in a medical home. The goal is to allow medical staff to be alerted at any time when a monitored person needs special attention or is in a critical situation. The application will inform the contextually more appropriate person (nurses, doctors) about the situation of the patient.

There is a big potential in monitoring people who need to be monitored. With this system these people could retrieve a bit of autonomy having the assurance of being observed in case something starts to go wrong.

1.2 Scope

The Elder Monitoring System (EMS) will be a proof of concept for the uMove Framework.

The main goal is to develop a system implementing the concept of Kinetic User Interface (KUI) and using uMove middleware.

KUI semantic model

KUI-based systems are intended to integrate the motions of users or objects in physical space where the motions are recognized and processed as meaningful events. The KUI model is a conceptual framework which can help in the design of pervasive systems including mobile applications or server-based systems integrating the user’s location, activities and other contexts such as spatio-temporal relations with other users.

uMove

uMove is Java API which implements the concept of KUI. It allows programmers to easily develop systems of observed entities (users, places, rooms, buildings). As shown in figure 1, the entities are objects created and managed in the e-space. There are attached to activity managers which process the data coming from the connected sensors. The entities are observed by the observer object which processes the situation of an entity each time a context changes. The applications are connected on top of the system and get the output of the observer. The advantage of this architecture is that a system is independently evolving (e.g. a medical home) and many specific applications can observe it and take actions when events are detected.

In this project, the entities will be the elders, the medical staff, the medical home with all rooms, the outside environment (e.g. the city).

There will be three parts to do:

server-based application It monitors the physical environment (city) and the building (medical home) and reports the state (motion, location, eventually physiological information) of the elders. It also locates and detects the activities of the medical staff. The goals of the server application are:

1. Tracking of the elders and storage of the current information and contexts.

Obs1

View1 View2

Activity

mng

Relation

mng

e-Spacee1

e12e11

e112

e111e1122e1121

Obs2 Obs3

Senget1

sensor1

Senget3

sensor3

Senget2

sensor2

Motion-aware application

Sen

so

r la

yer

En

tity

la

yer

Ob

serv

ati

on

layer

Situa-

tion

mng

Obs1

View1 View2

Activity

mng

Relation

mng

e-Spacee1

e12e11

e112

e111e1122e1121

Obs2 Obs3

Senget1

sensor1

Senget3

sensor3

Senget2

sensor2

Motion-aware application

Sen

so

r la

yer

En

tity

la

yer

Ob

serv

ati

on

layer

Situa-

tion

mng

Fig. 1 – uMove middleware



Page 5 of 22

2. Offer a graphical user interface to:

a. Manage the system (entities and sensors)

b. Monitor the system, using a map showing the location of the users.

3. Notify the medical staff only when an elder needs special attention.

Mobile application for elder people The elder’s mobile application has two main goals:

1. It processes the motion, location and the activity of the person. It detects locally if the person is doing something wrong or is missing something or is in a wrong place. For instance, if the person does something not allowed, he/she will receive a warning on the mobile device. This application has to be really easy to handle without big technological knowledge .

2. It transmits the elder’s situation to the server application in order to be processed

Mobile application for medical staff The second application will be for the nursing staff and provides information or alarm to the medical staff if an intervention is required.

The mobile application will communicate to the server-based application and transmits the data from the enabled sensors (Bluetooth, gps, …). The communication between the two uMove entities is provided. In this project the focus is set on the processing of the information and the feed back to the monitored person and medical staff.

The output of this project is an advanced prototype of academic use and marks an evaluation milestone of the uMove API (uMove, coordination, monitoring and mobile monitoring JARs), as it models and implements a concrete application within a real life context.

1.3 Terms & Abbreviations

Term Explanation

uMove

Elder situation Indicates the behavior and location of the elder, can be

- Normal

- Dangerous

- critical

Normal behavior slow movements just in one direction (accelerometer)

Strange behavior Fast movements in different directions (accelerometer)

Abbreviation Explanation

KUI Kinetic User Interface

GUI Graphical User Interface

EMS Elder person monitoring system

API application programming interface

SBA Server based application

MAEP Mobile application for elder person

MAMS Mobile application for medical staff



Page 6 of 22

BT Bluetooth

EP Elder person

MS Medical staff

RSSI Received Signal Strength Indication

1.4 References

Ref 1 Project_tasks_-_EMS.doc

Ref 2 Benjamin Hadorn, Coordination Model for Pervasive Computing: A model to create and design applications using a pervasive middleware

Ref 3 Bruegger et al. - Enriching the Design and Prototyping Loop: A set of tools to support the creation of activity-based pervasive applications – journal article

1.5 Requirements Coding

There are requirements described within this document. These requirements are listed in tables with a certain coding. The coding scheme is described as follow: SWRS-xxx-yy SWRS is referring to this document (Software Requirement Specification). xxx: is referring to a functional block according to the table below Coding of Requirements yy: is a consecutive number Every requirement is a must requirement. It is not allowed to delete or modify requirements. Requirements which are not applicable anymore have to be marked as N/A in a new line in the description field. It’s not allowed to reuse these numbers again to guarantee the traceability.

1.6 Priority Notation Description

1 Implementation of the Must point (must), basis functionality.

2 Wish point (should).

3 Proposition (can).

2 Overall Description

This section of the SWRS describes the general factors that affect the product and its requirements. This section does not state specific requirements. Instead, it provides a background for those requirements which are defined in detail in section 3 of this SWRS.



Page 7 of 22

2.1 Product Perspective

The following figure shows the scopes of the end product:

2.2 Product Functions

This project is a proof of concept for the uMove framework which has been developed in a PhD project of the University of Fribourg.

The project covers these main features:

- uMove evaluation: checking the usability of uMove as a middleware, reporting problems and bugs, Proposition of improvement.

- Indoor user tracking:

o Location: based on Bluetooth technology.

o Activity: detection on simple activity pattern (acting normally, acting stressfully, no motion)

- Raising alarms:



Page 8 of 22

o Sending alarms to the medical staff when critical user situation are detected. The situation are detected with a simple situation manager which triggers 3 types of messages:

� Normal situation

� Potentially dangerous

� Critical

o Proactively informing the monitored elder if something is detected to be wrong.

2.3 User Characteristics

The system has to be used by persons of three characteristics:

• elder people

• medical staff

• system administrator

2.3.1 Elder people

The elder people have to carry a mobile device with android operating system, but they should almost not have to interact with this device. (Maybe except for charging the accumulator).

2.3.2 Medical staff

Medical staff also has to carry a mobile device with android operation system. The medical staff has to be able to interact more with the application:Changing their status, checking the position of the elder persons, and handling alarms.

2.3.3 System administrator

The system administrator has to be able to set up the system, manage the rooms (i.e. changing attributes of a room like Bluetooth ID, room description), manage monitored persons within the uMove (i.e. nurses and elders), set up the alarm distribution and allowed zones.

2.4 Constraints

2.4.1 Regulatory Limitation

For this prototype there are no regulatory limitations.

2.4.2 Safety and Security Considerations

There are no safety and security considerations needed as this project states an advanced prototype and proof of concept for the uMove framework (at least in this phase of the project)

2.5 Assumptions and Dependencies

Mobile Operation System Android v2.0 and higher

Server Operation System Windows XP

The uMove Framework v2 developed by Pascal Bruegger must be used for the applications. The communication between the two uMove entities must be provided by the University of Fribourg

2.6 Apportioning of Requirements



Page 9 of 22

2.7 System requirements Req. ID Req. Types Requirement description Ref. Ref.Det.

SWRS-SYS-01

Functional The application must implement a KUI system

1

2.7.1 System interfaces Req. ID Req. Types Requirement description Ref. Ref.Det.

SWRS-SYS-02 Design Constraint

The System does not interact with other systems. There is only one server based application and one or more mobile applications for elder persons and one or more applications for medical staff

1

2.7.2 User interface

2.7.2.1 Server based application

Req. ID Req. Types Requirement description Ref. Ref.Det.

SWRS-SYS-03 Functional The user has the following Interfaces for interacting with the server based EMS application:

- Screen

- Keyboard

- Mouse

1

2.7.2.2 Mobile application


SWRS-SYS-04 Functional The user has the following Interfaces for interacting with the mobile EMS application:

- Touchscreen

1

2.7.3 Hardware Interface



The PAI Group of the University of Fribourg must allocate at least one mobile device with Android Operation system

1

2.7.4 Software interface



The application must use the uMove library 1

The PAI Group of the University of Fribourg must allocate a running version of uMove v2 and Coordination allowing the communication between server-based and mobile application including documentation and training as soon as possible



Page 10 of 22

2.7.5 Communication interface

The communication between the uMove entities must be provided by the client so there is no need to specify the communication interface here.

2.7.6 Storage limitation

There is no storage limitation for this project

2.7.7 Location specific requirements

There are no location specific requirements for this project



Page 11 of 22

3 Specific Software Requirements for server based application

2.8 General

��ABC�

DEFC��C�

��C�C�

��

E��

��

��

�CFF�C�

��ACFF��

��

��C�

��

�� !!��A��

��C

C��

C��C��

C��C��

C��C��

Figure 1: Overview of the server based application

For the server based application there will be two major parts to be done:

- Setting up the system with uMove library (actor, zones, viewers, situation manager) - Programming the EMS Application (Entity tracker, GUI)

Req. ID Req. Types Requirement description Ref. Priority

SWRS-GEN-01 Functional The application must be as modular as possible in order to be able to change modules without having to rewrite all the code

1 1

SWRS-GEN-02 Functional The applications must be clearly implemented and documented/commented in order to be extended and reused in other projects

1 1



Page 12 of 22

2.8.1 Use Cases

Figure 1: Use cases of the server based application

2.9 Set up the system

uMove is designed to autonomously discover new mobile devices with uMove running on it. So, any person carrying a uMove enabled device (elders or medical staff) will be discovered and managed automatically by the uMove framework when they will enter the building. In the setup the system administrator is able to modify system attributes. Req. ID Req. Types Requirement description Ref. Priority

SWRS-SUP-01 Functional It must be possible to define different safe locations for every elder person in the system depending on time and date

1 1

SWRS-SUP-02 Functional It must be possible to modify safe locations (position, time, date) for every elder person in the system

1 1

SWRS-SUP-03 Functional It must be possible to define persons of trust for every elder person

1 1



Page 13 of 22


SWRS-SUP-04 Functional It must be possible to modify persons of trust for every elder person

1 1

SWRS-SUP-05 Functional It must be possible to assign a specified Bluetooth ID to a room

1 1

SWRS-SUP-06 Functional It must be possible to modify the assigned Bluetooth ID to a room

1 1

2.10 Check condition of elder person

The SBA must allow the medical staff to check the actual condition of the elder person via the GUI. It should be possible to change the current view from tree view to floor plan view.

Figure 2: Tree view

For this advanced prototype the floor plan view will just be static. The prototype has to be able to manage and present multiple floors.. As there will be an indoor location tracking only, the position will be determined by the floor- and room number. Req. ID Req. Types Requirement description Ref. Priority

SWRS-CHC-01 Functional It must be possible for medical staff to find the actual location of a defined elder person Position:

- Floor No.

- Room No.

1 1

SWRS-CHC-02 Functional In the floor plan view there must be a tab for every floor

1 1

SWRS-CHC-03 Functional In the floor plan view the elder person must be defined as a point in the room including the name

Name:

- First name

- Last name

1 1

SWRS-CHC-04 Functional In the tree view every floor has to be its own tree like shown in Figure 2: Tree view

1 1



Page 14 of 22


SWRS-CHC-05 Functional In the tree view elder person must be defined as an entry containing the name.

Name:

- First name

- Last name

1 1

SWRS-CHC-06 Functional On clicking on the elder person in the GUI the medical staff must get information about the elder person:

Information:

- Actual location

- Actual activity

- Actual context (temperature)

- Actual situation (normal, dangerous, critical)

1 1

2.11 Receive location

The SBA will receive from the mobile applications the actual Bluetooth ID of the room where the sender is. The SBA has to know which BT-ID refers to which room and sends the room ID to the uMove Framework. The receiving of the data is a task of uMove and not one of this advanced prototype. Req. ID Req. Types Requirement description Ref. Priority

SWRS-REL-01 Functional The SBA must translate the received Bluetooth-ID into a room number

1 1

2.12 Receive situation

The SBA will receive from the EP mobile application the actual activity and context. The SBA will also receive from the MS mobile application the actual activity of the nurses. The receiving of the data is a task of uMove and not one of this advanced prototype. Received data from EP mobile app:

- Actual activity o Falling down o Strange behavior o Normal behavior o Not moving

- Context o Temperature o Location

Received data from MS mobile app:

- Actual activity o Making bed o With elder o Eating o Out



Page 15 of 22

2.13 Appraise situation

The SBA has to appraise the situation of the elder person by interpreting the received current activity and the contexts. There will be tree different states for the situation:

- Normal - Dangerous - Critical

Situation Situation

Activity: normal behavior and temperature between 36°C – 38°C Normal Temperature: below 36°C or above 38°C dangerous Activity: falling down and after 1 minute still not moving critical Activity: falling down after 1 minute strange behavior critical Activity: falling down after 1 minute normal behavior dangerous Activity: strange behavior dangerous Location: outside safe area dangerous Table 1: Situation of certain situations


SWRS-APS-01 Functional The SBA must decide in which situation

- Normal

- Dangerous

- critical

the elder person is according the Table 1: Situation of certain situations

1 1

2.14 Alarm escalation

If the SBA appraises the situation as dangerous or critical the SBA must alarm the person of trust. As priority 1 there will be just a simple alarm escalation. If the elder person is in a dangerous or critical situation, the next person of trust with an interruptible situation will get a message on the mobile device. As lower priority a more complex alarm escalation will be implemented. Req. ID Req. Types Requirement description Ref. Priority

SWRS-ALE-01 Functional If an elder person is in a dangerous or critical situation the SBA must alarm the nearest person of trust with an interrupt able situation.

1 1

SWRS-ALE-02 Functional If an elder person is in a dangerous situation the SBA should warn all persons of trust with an interruptible situation on the same floor.

1 2

SWRS-ALE-03 Functional If an elder person is in a critical situation the SBA should alarm the nearest person of trust with an interruptible situation.

1 2

SWRS-ALE-04 Functional If the person of trust doesn’t confirm the alarm message within 1 minute the SBA can alarm any nearest person of trust.

1 3



Page 16 of 22


SWRS-ALE-05 Functional If the person of trust doesn’t confirm the alarm message within 1 minute the SBA can alarm any nearest person of trust.

1 3

SWRS-ALE-05 Functional The alarming time interval can be set by the system administrator.

1 3

2.15 Alarming medical staff

After appraising the situation and checking which medical staff is the nearest, this person of trust must be alarmed. uMove will automatically send a message to the MS mobile application of the defined person of trust. Req. ID Req. Types Requirement description Ref. Priority

SWRS-ANS-01 Functional The SBA must pop up a window on the screen with an alarm message.

1 1

SWRS-ANS-01 Functional The SBA must send a message with the alarm to the mobile device of the person defined for the chosen escalation scenario.

1 1

SWRS-ANS-01 Functional In the alarm message there must be included the

- Actual location

- Actual activity

- Actual context (temperature)

- Actual situation (normal, dangerous, critical)

of the elder person which is in a critical or dangerous situation

1 1

2.16 Confirm alarm

If the person of trust accepts the alarm and is going to act accordingly, the person should be able to confirm the alarm message. The confirming is also important for the alarm escalation. Req. ID Req. Types Requirement description Ref. Priority

SWRS-COA-01 Functional The medical staff is able to confirm the alarm via their mobile device

1 3



Page 17 of 22

3 Specific Software Requirements for elder person mobile application

3.1 General

DEFC��C�

��C�C�

��

�CFF�C�

!��ACFF��

��

��C�

�� !!��A��

��C

AAC�C��C�C�

�CFF�C�

!��ACFF��

A��

��C�

�C�!�FC�F��"��C��#��C��AC

C��

C��

FC��C� FC��C� FC��C�

A��

Figure 3: Overview of the elder person mobile application

In this advanced prototype there will be no priority of power management. Req. ID Req. Types Requirement description Ref. Priority

SWRS-GEN-01 Functional The application must be as modular as possible in order to be able to change modules without having to rewrite all the code

1 1


1 1



Page 18 of 22

3.1.1 Use cases

Figure 4: Use cases of the elder person mobile application

3.2 Analyze of activity

Using the data from the accelerometer the MAEP must evaluate the activity of the elder person. There are just 3 different activities to detect in this advanced prototype:

- Normal behavior - Strange behavior - Fall down


SWRS-ANA-01 Functional The MAEP must be able to read out the accelerometer of the mobile device

1 1

SWRS-ANA-01 Functional The MAEP must be able to interpret the data from the accelerometer and decide it the elder person

- Has a normal behavior

- Has a strange behavior

- Falls down

1 1

3.3 Check temperature

The MAEP has to read out the internal temperature sensor from the mobile device. With this temperature the SBA will analyze the condition of the elder person. The mobile device must be directly connected to the body of the elder person, so the temperature should be about 37°C. Req. ID Req. Types Requirement description Ref. Priority



Page 19 of 22


SWRS-CHT-01 Functional The MAEP must be able to read out the temperature sensor of the mobile device

1 1

3.4 Check location

Using the Bluetooth ID the SBA will evaluate the location of the elder person. Every room will get a Bluetooth device with its fix own Bluetooth ID so there will be no problem to allocate the ID to the room number. If there are different location indicators available the MAEP has to choose the right one by measuring and interpreting the Bluetooth RSSI. Req. ID Req. Types Requirement description Ref. Priority

SWRS-CHL-01 Functional The MAEP must be able to receive the Bluetooth IDs of “location indicators”

1 1

SWRS-CHL-02 Functional The MAEP must be able to measure the RSSI of the Bluetooth “location indicators”

1 1

SWRS-CHL-03 Functional The MAEP has to choose the” location indicator” with the strongest RSSI with its ID saved in the SBA database.

1 1

3.5 Send context changes

Every context change must be sent to the SBA. uMove Framework will do this, so this is not part of this advanced prototype.

3.6 Alarming

The MAEP should alarm the elder person if he/she does something wrong or stands outside authorized location. Req. ID Req. Types Requirement description Ref. Priority

SWRS-ALA-01 Functional The MAEP can alarm the elder person with a sound when he/she is in a dangerous or critical situation

1 3

3.7 Usage of the mobile app

The usage of the MAEP must be as easy as possible. It is considered as ideal if the only interactions with the mobile device of the elder person would be the initial start up and the battery-charging. . uMove will login itself as soon as it detects a smart environment (uMove running on server). Req. ID Req. Types Requirement description Ref. Priority

SWRS-USA-01 Functional The MAEP should start up automatically when the mobile device starts up.

1 2



Page 20 of 22

4 Mobile application for medical staff requirements

4.1 General

In this advanced prototype there will be no priority of power management. Req. ID Req. Types Requirement description Ref. Priority

SWRS-GEN-01 Functional The application must be as modular as possible in order to be able to change modules without without having to rewrite all the code

1 1


1 1

4.1.1 Use Cases

Figure 5: Use cases of the medical staff mobile application

4.2 Alarming

The MAMS should alarm the medical staff if an elder person does something wrong or stands outside authorized location. Req. ID Req. Types Requirement description Ref. Priority

SWRS-ALM-01 Functional The MAMS must alarm medical staff by earcon when an elder person is in a dangerous situation

1 1



Page 21 of 22


SWRS- ALM -02 Functional The MAMS must alarm medical staff with a continuous earcon when an elder person is in a critical situation

1 1

SWRS- ALM -03 Functional The MAMS must show the from SBA received information about the elder person

- Location (floor and room number)

- Situation

- activity

in the screen

1 1

4.3 Confirm alarm

If the person of trust intents to act accordingly to the received alarm, the person of trust should be able to confirm that he/she takes care of the situation. The confirming is also important for the alarm escalation. Req. ID Req. Types Requirement description Ref. Priority

SWRS-CAM-01 Functional The medical staff can be able to confirm the alarm through the mobile app by pressing a confirm button on the touchscreen.

1 3

4.4 Change situation

The medical staff can change the actual activity status. This activity status will indicate the SBA if this person will be available for alarm or not. Req. ID Req. Types Requirement description Ref. Priority

SWRS-CSM-01 Functional The medical staff must be able to change the activity status.

Following stati will be defined:

- Making bed

- With elder person

- resting

- away

1 1

SWRS-CSM-02 Functional The status of medical staff can change according to the appointments in the mobile device’s calendar

1 3

4.5 Check location

Using the Bluetooth ID the SBA will evaluate the location of the elder person. Every room will get a Bluetooth device with its fix own Bluetooth ID so there will be no problem to allocate the ID to the room number. If there are different location indicators available the MAMS has to choose the right one by measuring and interpreting the Bluetooth RSSI. Req. ID Req. Types Requirement description Ref. Priority

SWRS-CLM-01 Functional The MAMS must be able to receive the Bluetooth IDs of “location indicators”

1 1



Page 22 of 22


SWRS-CLM-02 Functional The MAMS must be able to measure the RSSI of the Bluetooth “location indicators”

1 1

SWRS-CLM-03 Functional The MAMS has to choose the” location indicator” with the strongest RSSI with its ID saved in the SBA database.

1 1




The usage of the MAMS must be as easy as possible. It is considered as ideal if the only interactions with the mobile device of the elder person would be the initial start up and the battery-charging. . uMove will login itself as soon as it detects a smart environment (uMove running on server). Req. ID Req. Types Requirement description Ref. Priority

SWRS-USA-01 Functional The MAEP should start up automatically when the mobile device starts up.

1 2

5 Documentation Req. ID Req. Types Requirement description Ref. Priority

SWRS-DOC-01 Design Constraint

A Design Description must be written for this project

All applications must be described using UML and clear diagrams.

1 1

SWRS-DOC-02 Design Constraint

An evaluation of the uMove API (umove, coordination, monitoring and mobile monitoring JARs) must be written containing the following points:

- Usability of uMove (programming point of view)

- Problems and bugs encountered - Proposition of improvement.

1 1

6 Document history

Version Date Creator Description of modification 0.1 17.04.2010 René Süssmilch Newly created

0.2 26.04.2010 René Süssmilch Adjusted after review with P. Bruegger

0.3 28.04.2010 René Süssmilch Adjusted after review with P. Bruegger and M. Adam

1.0 29.04.2010 René Süssmilch

T-213-10 / V 1 EMS_Doc-v1.0.doc

Page 1 of 50

Compare with the valid version before usage of printed documents!

Process:

Software Description


Number MT-10-01.14

Version: 1.0


Template:




Postfach 325, CH-3000 Bern 22, [email protected], +41 31 84 83 272 Keywords uMove, Elderly person, monitoring, KUI, kinetic user interface

Release



Software Description Version 1.0

T-213-01 / V 1 EMS_Doc-v1.0.doc

Page 2 of 50

Abstract

This project is intended to test the usability of the uMove development framework developed in the context of a PhD project at the university of Fribourg. The goal of this project is to create an application which monitors elderly persons in an nursing home environment and helps the medical staff to get information about the residents and their potential intervention if any resident’s situation requires it.

Within this proof of concept study I realized a functional elderly monitoring system including the server based application and the two different mobile applications for the elderly persons and the medical staff. The applications were planned and realized as fast prototypes.

This project was the first one which used the uMove framework of the PAI Group of the University of Fribourg in its complete functionality. It required more reworks of the EMS software and time due to the reason that some parts of the framework were still under development and the documentation not daily updated. This means that not all of the requirements specified in the Software requirement specification are implemented. Together with the advisor and expert I had to set certain priorities with focus of the uMove parts. Anyhow, studying the framework code and the helping hand of the adviser Pascal Bruegger helped to understand the functionality and usage of the uMove framework.

During this project working with this framework, I got the estimation that the uMove framework is a really powerful and serviceable utility to implement such a kinetic user interface application like this elderly monitoring system.


T-213-01 / V 1 EMS_Doc-v1.0.doc

Page 3 of 50

Abstract 2�

1� Introduction 6�

1.1� Purpose .............................................................................................................................. 6�

1.2� Scope ................................................................................................................................. 6�

1.3� Terms & Abbreviations ....................................................................................................... 8�

1.4� References ......................................................................................................................... 9�

2� Project Description 10�

2.1� System Overview .............................................................................................................. 10�

2.2� Server Based Application (SBA) ....................................................................................... 11�2.2.1� Use Case of the server based application ................................................................... 11�2.2.2� Use Case Description .................................................................................................. 12�

2.3� Mobile Application for elderly person (MAEP) ................................................................... 14�2.3.1� Use Case of the mobile application for elderly person ................................................. 14�2.3.2� Use case description ................................................................................................... 14�

2.4� Mobile Application for medical staff (MAMS) ..................................................................... 18�2.4.1� Use case of the mobile application for medical staff .................................................... 18�2.4.2� Use case description ................................................................................................... 18�

3� Used Technologies 21�

3.1� Java .................................................................................................................................. 21�

3.2� Android ............................................................................................................................. 21�

3.3� WLAN ............................................................................................................................... 21�

3.4� Bluetooth .......................................................................................................................... 21�

3.5� Motorola Milestone ........................................................................................................... 21�

4� Design description 22�

4.1� Layout of the System ........................................................................................................ 22�

4.2� Setup the KUI Server System ........................................................................................... 22�4.2.1� Alarm communication .................................................................................................. 23�

4.2.1.1� Send Dangerous Message Design ................................................... 24�4.2.1.2� SendCriticalMessage Design ........................................................... 25�

4.3� Store elderly person and medical staff data ...................................................................... 25�4.3.1� Definition of elderly person .......................................................................................... 26�4.3.2� Definition of medical staff ............................................................................................ 26�4.3.3� XML Schema............................................................................................................... 26�

4.4� Motion detection with accelerometer ................................................................................. 27�

4.5� Reading temperature ........................................................................................................ 28�

5� Implementation 29�

5.1� Server implementation ...................................................................................................... 29�5.1.1� GUI ............................................................................................................................. 29�

5.1.1.1� General application GUI ................................................................... 29�5.1.1.2� Managing elderly person .................................................................. 30�

5.1.1.2.1� Add new elderly person .......................................................... 30�


T-213-01 / V 1 EMS_Doc-v1.0.doc

Page 4 of 50

5.1.1.2.2� Modify elderly person .............................................................. 32�5.1.1.3� Manage medical staff ....................................................................... 33�

5.1.1.3.1� Add new medical staff ............................................................. 33�5.1.2� Class diagram ............................................................................................................. 35�5.1.3� Class description ......................................................................................................... 36�

5.1.3.1� EMSMain ......................................................................................... 36�5.1.3.2� Person ............................................................................................. 36�5.1.3.3� MedicalStaff ..................................................................................... 36�5.1.3.4� ElderPerson ..................................................................................... 36�5.1.3.5� Location ........................................................................................... 36�5.1.3.6� SafeLocation .................................................................................... 36�5.1.3.7� XMLReader ...................................................................................... 36�5.1.3.8� EntityTracker .................................................................................... 36�5.1.3.9� EMSSituationManager ..................................................................... 36�5.1.3.10� TimedActivity .................................................................................... 36�5.1.3.11� GUI classes ...................................................................................... 36�

5.1.4� Implementing uMove ................................................................................................... 37�5.1.4.1� Entity layer ....................................................................................... 37�

5.1.5� Observation layer ........................................................................................................ 38�5.1.5.1� View ................................................................................................. 38�5.1.5.2� Observer .......................................................................................... 38�5.1.5.3� Situation manager ............................................................................ 38�

5.1.6� Communication between Server and mobile app ........................................................ 40�5.1.7� SendDangerousMessage ............................................................................................ 40�5.1.1� SendCriticalMessage .................................................................................................. 41�5.1.2� XML Parser ................................................................................................................. 42�

5.2� Mobile Application for elderly person ................................................................................ 43�5.2.1� Class diagram ............................................................................................................. 43�5.2.2� Class description ......................................................................................................... 44�

5.2.2.1� Main Activity ..................................................................................... 44�5.2.2.2� SettingsForm .................................................................................... 44�5.2.2.3� AndroidMobile .................................................................................. 44�5.2.2.4� DiscoveryService ............................................................................. 44�5.2.2.5� DiscoveryBinder ............................................................................... 44�5.2.2.6� RemoteBTDevice ............................................................................. 44�5.2.2.7� AndroidTempSensor ........................................................................ 44�5.2.2.8� AndroidAccSensor ........................................................................... 44�5.2.2.9� MobileActivityManager ..................................................................... 44�5.2.2.10� MobileSituationManager ................................................................... 44�5.2.2.11� UnknownLocationTagProcessor ....................................................... 44�5.2.2.12� MobileActivitySengetMessageProcessor .......................................... 44�

5.2.3� Location Tracking ........................................................................................................ 45�5.2.3.1� Bluetooth Location Tracking ............................................................. 45�

5.2.3.1.1� Problems with Bluetooth in Android ........................................ 45�5.2.3.1.2� Sequence diagram of the Bluetooth Service ........................... 45�5.2.3.1.3� Setting up “location indicators” ................................................ 46�5.2.3.1.4� Test ........................................................................................ 46�5.2.3.1.5� Improvement........................................................................... 46�

5.2.3.2� Possible alternatives ........................................................................ 46�5.2.3.2.1� RFID ....................................................................................... 47�5.2.3.2.2� Wireless LAN .......................................................................... 47�

5.3� Mobile application for medical staff ................................................................................... 48�


T-213-01 / V 1 EMS_Doc-v1.0.doc

Page 5 of 50

5.3.1� Class diagram ............................................................................................................. 48�5.3.2� Class description ......................................................................................................... 49�

5.3.2.1� MainActivity ...................................................................................... 49�5.3.2.2� SettingsForm .................................................................................... 49�5.3.2.3� AlarmMessageBox ........................................................................... 49�5.3.2.4� AndroidMobile .................................................................................. 49�5.3.2.5� Continuous alarm task ...................................................................... 49�5.3.2.6� Babel ................................................................................................ 49�5.3.2.7� LocalizedString................................................................................. 49�5.3.2.8� DiscoveryService ............................................................................. 49�5.3.2.9� DiscoveryBinder ............................................................................... 49�5.3.2.10� RemoteBTDevice ............................................................................. 49�5.3.2.11� MobileActivityManager ..................................................................... 49�5.3.2.12� MobileSituationManager ................................................................... 49�5.3.2.13� UnknownLocationTagProcessor ....................................................... 49�5.3.2.14� MobileActivitySengetMessageProcessor .......................................... 49�

5.3.3� Location tracking ......................................................................................................... 50�5.3.4� Text to speech ............................................................................................................. 50�


T-213-01 / V 1 EMS_Doc-v1.0.doc

Page 6 of 50

1 Introduction

1.1 Purpose

The EMS project focuses on an application which monitors elderly or impaired people living alone or in a medical home. The goal is to allow medical staff to be alerted at any time when a monitored person needs special attention or is in a critical situation. The application will inform the contextually more appropriate person (nurses, doctors) about the situation of the patient. There is a big potential in monitoring people who need regular support and assistance. With this system, these people could retrieve their autonomy by being observed in an unobtrusive manner and being confident to get assistance in case something starts to go wrong.

1.2 Scope

The Elder Monitoring System (EMS) will be a proof of concept for the uMove Framework. The main goal is to develop a system implementing the concept of Kinetic User Interface (KUI) and using uMove framework. Please see [Ref. 4] to get more general information about uMove.

KUI semantic model KUI-based systems intend to integrate the motions of users or objects in physical space where the motions are recognized and processed as meaningful events. The KUI model is a conceptual framework which can help in the design of pervasive systems including mobile applications or server-based systems integrating the user’s location, activities and other contexts such as spatio-temporal relations with other users.

uMove uMove is Java API which implements the concept of KUI. It allows programmers to easily develop systems of observed entities (users, places, rooms, buildings). As shown in figure 1, the entities are objects created and managed in the e-space. They are attached to activity managers processing the data coming from the connected sensors. The entities are observed by the observer object which processes the situation of an entity each time a context changes. The applications are connected on top of the system and get the output of the observer. The advantage of this architecture is that a system is independently evolving (e.g. a medical home) and many specific applications can observe it and take actions when events are detected. In this project, the entities will be the elders, the medical staff, the medical home with all rooms.

Figure 1: KUI System


T-213-01 / V 1 EMS_Doc-v1.0.doc

Page 7 of 50

The Application of the Elderly Monitoring System is divided into a server based and two kinds of mobile applications for the following Users Group:

• The server application allows system administrator and supervisor to set up, change, control and check the system

• One mobile application is aimed for the elderly or impaired person (Monitored Persons) whereas a second one is aimed for the medical staff like nurses, doctors, … (Guided Persons)

Figure 2: Overview of the applications

server-based application It monitors the physical environment (city) and the building (medical home) and reports the state (motion, location, eventually physiological information) of the elders. It also locates and detects the activities of the medical staff. The goals of the server application are:

1. Tracking of the elders and storage of the current information and contexts.

2. Offer a graphical user interface which allows to:

a. Manage the system (entities and sensors)

b. Monitor the system, using a map showing the location of the users.

3. Notify the medical staff only when an resident needs special attention and/or care.

Mobile application for elderly people The elder’s mobile application has two main goals:


T-213-01 / V 1 EMS_Doc-v1.0.doc

Page 8 of 50

1. It processes the motion, location and the activity of the person. It detects locally if the person is doing something wrong or is missing something or is in a wrong place. For instance, if the person does something he/she is not allowed to do, he/she will receive a warning on the mobile device. This application has to be really easy to handle without big technological knowledge.

2. It transmits the resident’s situation to the server application in order to be processed.

Mobile application for medical staff The second application will be for the medical staff (nurses and doctors) and provides information or alarms if an intervention is required. The mobile application will communicate to the server-based application and transmits the data from the enabled sensors (Bluetooth, gps). The communication between the a server based application with uMove and a mobile application with uMove is provided. In this project the focus is set on the processing of the information and the feed back to the monitored person and medical staff. The output of this project is an advanced prototype for academic purposes and an evaluation of the usability of the uMove API (uMove, coordination, monitoring and mobile monitoring JARs) for modeling and the implementation of concrete applications in real programming contexts.

1.3 Terms & Abbreviations

Term Explanation

uMove uMove is Java API which implements the concept of KUI. It allows programmers to easily develop systems of observed entities (users, places, rooms, buildings). See Ref 4

Elder situation Indicates the behavior and location of the elder, can be

- Normal

- Dangerous

- critical

Normal behavior Slow movements just in one direction (accelerometer)

Strange behavior Fast movements in different directions (accelerometer)

Abbreviation Explanation

KUI Kinetic User Interface

GUI Graphical User Interface

EMS Elder person monitoring system

API application programming interface

SBA Server based application

MAEP Mobile application for elderly person

MAMS Mobile application for medical staff

BT Bluetooth

EP Elder person

MS Medical staff

RSSI Received Signal Strength Indication


T-213-01 / V 1 EMS_Doc-v1.0.doc

Page 9 of 50

1.4 References

Ref 1 Pascal Bruegger, Project_tasks_-_EMS.doc

Ref 2 Benjamin Hadorn, Coordination Model for Pervasive Computing: A model to create and design applications using a pervasive middleware

Ref 3 Bruegger et al. - Enriching the Design and Prototyping Loop: A set of tools to support the creation of activity-based pervasive applications – journal article

Ref 4 Bruegger, Pascal, Hadorn, Benjamin and Hirsbrunner, Béat: SSP: Smart Service Provider - A Smart Environment Providing Contextual Services on Android Mobile Devices, Springer LNCS, UIC 2010, Xi'an - China, October,2010.

Ref 5

Bruegger, Pascal and Hirsbrunner, Béat, Kinetic User Interface: Interaction through Motion for Pervasive Computing Systems, in: Parallel session "Designing for Mobile Computing", Springer, HCI international conference 2009, San Diego, California, USA, July, 2009

Ref 6 René Süssmilch, Software Requirements specification_v1.0.doc


T-213-01 / V 1 EMS_Doc-v1.0.doc

Page 10 of 50

2 Project Description

2.1 System Overview

uMove

EMS app

sensors

Elder

Location, motion data

Alarms

Alarms, feedback

EMS server-based application

Intervention required

Figure 3: General diagram of the EMS application (server and mobile)


T-213-01 / V 1 EMS_Doc-v1.0.doc

Page 11 of 50

The elderly monitoring system can be divided into 3 main parts: 1. The server based application SBA 2. A mobile application for the elderly person (MAEP) 3. A mobile application for the medical staff (MAMS)

Figure 3: General diagram of the EMS application (server and mobile). Every elderly person and also every member of the medical staff will get a mobile device with the accordant app on it.

2.2 Server Based Application (SBA)

It monitors the physical environment (city) and the building (nursing home) and reports the state (activity, location, temperature, possibly physiological information) of the elders. The goal is to allow nurses to easily get information on the screen about the population of the building. So the mobile app of the elderly person has to send the collected data to the server. The server app has to detect, if the elderly person is in a dangerous or critical situation and in case of dangerous or critical situation the server app has to alarm the elderly person’s person of trust.

2.2.1 Use Case of the server based application

Figure 4: Use case diagram of SBA


T-213-01 / V 1 EMS_Doc-v1.0.doc

Page 12 of 50

2.2.2 Use Case Description

Name Login Short description Login is allocated by uMove. In the login the MA receive the

identifiers of every monitored room in this building activator MAEP / MAMS a login command to EMS SBA actor MAEP / MAMS Pre-condition n/a Post condition MAEP / MAMS is logged in in this SBA, MAEP / MAMS know

all Room identifiers action 1. Log in the MEAP /MAMS

2. send room identifiers 3. update GUI

variation Exceptions, mistakes rules Included use cases Update GUI remarks Open questions version V1, 05.07.2010 Name Change Context Short description Capture a context change (Temperature) and appraise the

situation activator MAEP sends a new context of the EP actor MAEP Pre-condition EP is set up in the system Post condition GUI is updated, context is saved, MS is alarmed action 1. Receive new context

2. update the context of the EP in the GUI 3. new situation must be appraised 4.1 if situation is critical or dangerous MS must be alarmed 4.2 if situation is critical or dangerous update status in GUI

variation Exceptions, mistakes rules Included use cases Update GUI

Appraise situation of EP Alarming medical staff

remarks Open questions version V1, 05.07.2010 Name Change location Short description Capture a location change and appraise the situation activator MAEP / MAMS sends a new location of the EP/MS actor MAEP / MAMS Pre-condition EP / MS is set up in the system Post condition GUI is updated, location is saved, MS is alarmed


T-213-01 / V 1 EMS_Doc-v1.0.doc

Page 13 of 50

action 4. Receive new position 5. update the position of the EP/MS in the GUI 6. If the sender is a EP the new situation must be

appraised 4.3 if situation is critical or dangerous: MS must be alarmed 4.4 if situation is critical or dangerous: update status in GUI



remarks Open questions version V1, 05.07.2010 Name Change activity Short description Capture an activity change and appraise the situation activator MAEP / MAMS sends a new activity of the EP/MS actor MAEP / MAMS Pre-condition EP / MS is set up in the system Post condition GUI is updated, location is saved, MS is alarmed action 1. Receive new position

2. update the position of the EP/MS in the GUI 3. If the sender is a EP the new situation must be

appraised 4.1 if situation is critical or dangerous MS must be alarmed 4.2 if situation is critical or dangerous update status in GUI



remarks Open questions version V1, 05.07.2010


T-213-01 / V 1 EMS_Doc-v1.0.doc

Page 14 of 50

2.3 Mobile Application for elderly person (MAEP)

2.3.1 Use Case of the mobile application for elderly person

Figure 5: Use Case diagram of the MEAP

2.3.2 Use case description

Name Set up Short description The system administrator can set up the mobile app. That

means he can set up the name of the elderly person activator The sys admin presses the Settings button actor System administrator Pre-condition The mobile app is running, a connection to the server based

app can be arranged via WLAN Post condition The mobile app is running, a connection to the server based

app can be arranged via WLAN action 1. Showing the settings window

2. Tip in the new name 3. Change the name in the settings

variation Exceptions, mistakes rules Included use cases - remarks Open questions version V1, 05.08.2010


T-213-01 / V 1 EMS_Doc-v1.0.doc

Page 15 of 50

Name Read temperature Short description The system reads the actual temperature from the internal

temperature sensor activator Internal sensor timer from Android actor Temperature sensor Pre-condition The mobile app is running, the mobile device includes a

temperature sensor Post condition The mobile app is running, the mobile device includes a

temperature sensor action 1. Read the temperature on every timer event variation Exceptions, mistakes rules Included use cases - remarks Open questions version V1, 05.08.2010 Name Read all Bluetooth IDs including their RSSI Short description The system reads all available Bluetooth device IDs including

their RSSI activator Start of the application, end of the Bluetooth discovery actor Bluetooth interface Pre-condition The mobile app is running, the mobile device includes a

running Bluetooth interface Post condition The mobile app is running, the mobile device includes a

running Bluetooth interface action 1. Search device

2. Read RSSI 3. Store Device ID and RSSI in a list 1. Repeat step 1 to 3 until all devices found



T-213-01 / V 1 EMS_Doc-v1.0.doc

Page 16 of 50

Name Read acceleration Short description The system reads the values of all three axes of the

accelerometer activator Internal sensor timer from Android actor accelerometer Pre-condition The mobile app is running, the mobile device includes an

accelerometer sensor Post condition The mobile app is running, the mobile device includes an

accelerometer sensor action 1. Read out and store x-axis acceleration value

2. Read out and store y-axis acceleration value 3. Read out and store z-axis acceleration value

variation Exceptions, mistakes rules Included use cases - remarks Open questions version V1, 05.08.2010 Name Dispatch Location Short description The actual position will be evaluated out of the list with the

actual Bluetooth IDs and their RSSI activator End of a Bluetooth discovery actor MEAP Pre-condition A Bluetooth discovery was started and finished Post condition The mobile app is running, the mobile device includes a

running Bluetooth interface action 1. Check if Bluetooth id from the EMS

2. Search the Bluetooth device with the strongest RSSI variation Exceptions, mistakes rules Included use cases Read Bluetooth id remarks Open questions version V1, 05.08.2010


T-213-01 / V 1 EMS_Doc-v1.0.doc

Page 17 of 50

Name Dispatch activity Short description The actual activity will be evaluated out of the list with the

acceleration values of all 3 axes during 800ms activator End of a the measure time (800ms) actor MEAP Pre-condition The acceleration measurement was finished Post condition The mobile app is running action 1. Calculate the average of the acceleration

2. Check the average and decide which activity variation Exceptions, mistakes rules Included use cases Read acceleration remarks Open questions version V1, 05.08.2010 Name Send context change Short description If there is a change of location or temperature, this change

muss be sent to the SBA activator Temperature or location change actor MEAP Pre-condition The MEAP is running, a connection to the SBA exists Post condition The MEAP is running, a connection to the SBA exists action 1. Receive change

2. Send change to SBA variation Exceptions, mistakes rules Included use cases - Dispatch location

- Dispatch activity remarks Open questions version V1, 05.08.2010


T-213-01 / V 1 EMS_Doc-v1.0.doc

Page 18 of 50

2.4 Mobile Application for medical staff (MAMS)

2.4.1 Use case of the mobile application for medical staff

Figure 6: Use Cases MAMS

2.4.2 Use case description

Name Set up Short description The system administrator can set up the mobile app. That

means he can set up the name of the medical staff activator The sys admin presses the Settings button actor System administrator Pre-condition The mobile app is running, a connection to the server based

app can be arranged via WLAN Post condition The mobile app is running, a connection to the server based

app can be arranged via WLAN action 1. Showing the settings window

2. Tip in the new name 3. Change the name in the settings



T-213-01 / V 1 EMS_Doc-v1.0.doc

Page 19 of 50

Name Read all Bluetooth IDs including their RSSI Short description The system reads all available Bluetooth device IDs including

their RSSI activator Start of the application, end of the Bluetooth discovery actor Bluetooth interface Pre-condition The mobile app is running, the mobile device includes a

running Bluetooth interface Post condition The mobile app is running, the mobile device includes a

running Bluetooth interface action 1. Search device

2. Read RSSI 3. Store Device ID and RSSI in a list 4. Repeat step 1 to 3 until all devices found

variation Exceptions, mistakes rules Included use cases - remarks Open questions version V1, 05.08.2010 Name Dispatch Location Short description The actual position will be evaluated out of the list with the

actual Bluetooth IDs and their RSSI activator End of a Bluetooth discovery actor MEAP Pre-condition A Bluetooth discovery was started and finished Post condition The mobile app is running, the mobile device includes a

running Bluetooth interface action 1. Check if Bluetooth id from the EMS

2. Search the Bluetooth device with the strongest RSSI variation Exceptions, mistakes rules Included use cases Read Bluetooth id remarks Open questions version V1, 05.08.2010


T-213-01 / V 1 EMS_Doc-v1.0.doc

Page 20 of 50

Name Change activity Short description The Medical staff changes its activity in the GUI activator Activity change via GUI actor Medical staff Pre-condition The mobile app is running, a connection to the server is

arranged Post condition The mobile app is running action 1. Read the actual activity form GUO variation Exceptions, mistakes rules Included use cases - remarks Open questions version V1, 05.08.2010 Name Send context change Short description If there is a change of location, this change muss be sent to the

SBA activator location change actor MEAP Pre-condition The MEAP is running, a connection to the SBA exists Post condition The MEAP is running, a connection to the SBA exists action 1. Receive change

2. Send change to SBA variation Exceptions, mistakes rules Included use cases - Dispatch location

- change activity remarks Open questions version V1, 05.08.2010


T-213-01 / V 1 EMS_Doc-v1.0.doc

Page 21 of 50

3 Used Technologies

The EMS project uses the following technologies:

3.1 Java

Java is a high-level object oriented programming language developed by Sun Microsystems. Java started as a part of web services, web application and a platform independent programming language in the 1990s. Java 1.0 was officially release in the Year 1995. In this project Java in the Version 1.6.0_13 and Netbeans Integrated Development Environment IDE version 6.8 is used.

3.2 Android

Android is an operating system for mobile devices such as mobile phones, tablet computer etc. Android is developed by Google and is based upon the Linux kernel and GNU software. With the exception of brief update periods, Android has been available as open source since 21 October 2008. Google opened the entire source code (including network and telephony stack) under an Apache License Design description. The version of Android changed from October 2008 until May 2010 from 1.0 to 2.2. The possibility of the interaction of the mobile device with Global Positioning System (GPS), accelerometer sensors and also with temperature sensors is part of the main concept of android In this project Android2.0 is used as the provided devices (Motorola Milestone) work on Android 2.0

3.3 WLAN

WLAN is a common standard for data exchange, used for the complete communication between the server based application and mobile application within this application.

3.4 Bluetooth

Bluetooth is a by now well-established communications standard for short-distance wireless connections. It replaces the many proprietary cables that connect one device to another with one universal short-range radio link. Bluetooth allows reading the signal strength of all available radio nodes. This property allows the implementation of a location tracking by interpreting the signal strength (RSSI received signal strength indicator).

3.5 Motorola Milestone

As mobile device for the elderly person and also the medical staff, the Motorola Milestone will be used. This mobile device uses Android 2.0 as operating systems which provides a Java Virtual Machine that is compatible with Java Standard Edition. This allows us to develop a mobile application using the same pervasive middle ware as we use for the server application. It also offers access to several sensors like 3 axes accelerometer, temperature sensor and others. It also includes connectivity like Bluetooth and WLAN required for this project. For setting up the mobile phone to install the uMove framework see [Ref 2]


T-213-01 / V 1 EMS_Doc-v1.0.doc

Page 22 of 50

4 Design description

4.1 Layout of the System

The implementation of the elderly monitoring system is split into tree applications, the server based application, a mobile app for the elderly person and a mobile app for the nursing staff.

• Server application: the server based application implements pervasive services in the environment.

• Mobile application for elderly person: the mobile application runs on a mobile device using its embedded sensors (temperature sensor, accelerometer) and also its Bluetooth device for the location tracking and WLAN for the communication with the server application. It monitors the elderly person and sends context changes to the server application

• Mobile application for nursing staff: the mobile application runs also on a mobile device. It just uses its Bluetooth device for the location tracking and WLAN for the communication with the server application. Activity changes will be set by the user via GUI

All these three systems are based on the pervasive middleware; the uMove Framework that represents the illustration of the surrounding area, the coordination component manages the communication and the monitoring detects the mobile entities.

��

��A�

BAC�DE

F�A�C��

��C

BAC��C��

��C

City

Building

Floor 3

Floor 4

A303 A304 A305 A306 A307 A403 A404 A405

��

��A�

BAC�DE

F�A�C��

��C

BAC��C��

��C

��

��C

��B��D��D��D�� B��D��A��C��

��D�D��A�C��

��

��D�A��

��C

B��D��

��

��

��D�A�B��D��

��D�A�

��

��D�A��

��C

B��D��

��D�A��

��C

Figure 7: Setup of server and mobile applications

4.2 Setup the KUI Server System

After a general introduction of the Definition of a KUI System and the uMove Framework including studying the existing Robin demo – application, it was possible to set up and extend the KUI System for the EMS project.


T-213-01 / V 1 EMS_Doc-v1.0.doc

Page 23 of 50

We extended an existing pervasive application called Robin which we received from Pascal Bruegger. This Robin Project was a case study to show how uMove is used to build activity based pervasive applications. There were some major parts to do:

• Setting up Entity layer: The entity layer comprises the e-space, the activity management and relation management

• Setting up Sensor Layer: Create the sensor sengets [Ref4]

• Setting up Observation Layer: Creating views, observers and the situation management On top of this KUI System the next and major part of this project was to implement an elderly monitoring System.

4.2.1 Alarm communication

City

Building

Floor 3

Floor 4

A303 A304 A305 A306 A307 A403 A404 A405

Actor Stub

Figure 8: Communication between SBA and MAMS

Normally the communication between SBA and the mobile device is automatically managed by the uMove Framework. In the Figure 8: Communication between SBA and MAMS we can see the message exchange between the KUI Service Session of the Server and Client System through the KUI Service. This exchange of messages creates a stub for the mobile actor on the server side so it is recognized in the server app. Context changes and also activity changes will be sent through this stub. The alarm service is an application specific service. With this service the medical staff will be alarmed when a patient to whom the medical staff is responsible of, is in a dangerous or critical situation. If the same service is used for the medical staff in order to be able to accept or reject the alarm, the service is implemented as a bidirectional communication. The class EntityTracker processes the situation of the entity and sends a message via the alarm service to the medical staff. There are two different alarming methods to send an alarm message from the SBA to the mobile application:

• SendDangerousMessage: this method searches the geographical nearest person of trust of the elderly person beeing in a dangerous situation and sends him or her an alarm message.

• SendCriticalMessage: this method alarms all persons of trust on the same floor that this elderly person is in a critical situation.


T-213-01 / V 1 EMS_Doc-v1.0.doc

Page 24 of 50

4.2.1.1 Send Dangerous Message Design

Figure 9: State diagram sendDangerousMessage

The sendDangerousMessage method searches all medical staff on the same floor then checks which members of the medical staff are persons of trust for this elderly person. For every person of trust, the distance vector will be calculated and so the geographical next person of trust will be alarmed.


T-213-01 / V 1 EMS_Doc-v1.0.doc

Page 25 of 50

4.2.1.2 SendCriticalMessage Design

Figure 10: State diagram sendCriticalMessage

The sendCriticalMessage method searches all medical staff on the same floor then checks which members of the medical staff are persons of trust for this elderly person. Every person of trust will be alarmed when the elderly person is in a critical situation.

4.3 Store elderly person and medical staff data

For storing the data of the elderly person and also the medical staff we choose Extensible Markup Language (XML) this can be done as we don’t have to store data during the application is running and hence it wouldn’t make sense to use a database like SQL. By adapting this XML-config file with a common XML writer the system administrator is able to set up, change and delete data of all elderly persons and medical staff This interface allows us to implement a nice and proper GUI in the future.


T-213-01 / V 1 EMS_Doc-v1.0.doc

Page 26 of 50

4.3.1 Definition of elderly person

Listening 1: XML definition of an elderly person

As described in the Listening 1: XML definition of an elderly person all person details are defined as attributes (name, prename, initial_location, patient_number). The attribute patient_number must be unique in the system. In the element SafeLocations the system administrator can define as many safeLocations as are required for this elderly person In the element Medicals the personOfTrust can be defined for this elderly person (just the personal number of the medical staff is needed). A defined XML schema checks the written definition of the elderly person.

4.3.2 Definition of medical staff

Listening 2: XML definition of a member of the medical staff

As described in Listening 2: XML definition of a member of the medical staff all person details of a member of the medical staff are defined as attributes (name, prename, initial_location, personal_number). The attribute personal_number must be unique in the system. A defined XML schema checks the written definition of member of the medical staff.

4.3.3 XML Schema

To make the defined XML description safe for the implemented XML parser in the EMS application we defined a XML Schema.

<MedicalStaff name="Meier" personal_number="123" prename="Hans" initial_location="A404"/>

<ElderPerson name="Schneider" prename="Vreni" initial_location="A403" patient_number="1234"> <SafeLocations> <SafeLocation end_time="23:59:59" countinious="true" location="A403" start_time="00:00:00"/> <SafeLocation end_time="23:59:59" countinious="true" location="A303" start_time="00:00:00"/> </SafeLocations>

<Medicals> <PersonOfTrust personal_number="123"/> <PersonOfTrust personal_number="124"/> </Medicals> </ElderPerson>


T-213-01 / V 1 EMS_Doc-v1.0.doc

Page 27 of 50

4.4 Motion detection with accelerometer

For this subject a complete master thesis is set up at the University of Fribourg. This is the reason why we implemented a rather simple model in this project, that can be replaced by any more sophisticated model in the future. According to some other master thesis found in the internet, a good interval for making a fall detection is 800ms. During this 800ms enough measurements were done and a fall should be detectable. We implemented the motion detection like this: 1. Measure the accelerometer values during 800ms 2. Integrate the absolute value of the addition of x-, y- and z-axis

Formula 1: absolute value of the acceleration vector

3. Divide the result of the integration through the count of values

Formula 2: Average of the acceleration during 800ms

Normally if there is no movement of the mobile the average over this 800ms is 9.81(m/s), that is the earth gravity. If the elderly person moves or falls the average will be lower than the earth gravity because the person moves in the same direction as the gravity works. So we can say that in a case of a fall the average should be almost zero because the body moves in the same direction and with the same acceleration as the gravity. In real this average will not be zero because of the rotation that the bodypwill do during the fall. Because of the jitter of the sensor the value is a bit higher. So we set the border for the movements like this: averageAcc motion 9.75 < averageAcc <= 10.00 Not move 9.00 < averageAcc <= 9.75 || 10.00 < averageAcc <= 11 Normal behavior 8.00< averageAcc <= 9.00 || 11 < averageAcc <= 12 Strange behavior averageAcc <= 8.00 || 12 < averageAcc Fall This is an absolutely simplified algorithm, but this problem is a whole theme of other master thesis, so not that much time was invested in this problem. There is just a simple implementation that the situation manager of the SBA can work with an activity change. Due to the simplify of this algorithm not acceptance test was done. There will be a much better algorithm out of another master thesis. In order to limit the traffic from mobile to server application only a change of motion will be sent to the server.


T-213-01 / V 1 EMS_Doc-v1.0.doc

Page 28 of 50

4.5 Reading temperature

The mobile application for elderly person MAEP reads the temperature sensor of the Android mobile device with the rate SensorManager. SENSOR_DELAY_NORMAL. This is the default rate and it is fast enough. In order to limit the traffic from mobile to server application a context (temperature) change will just be sent when the temperature change is higher than 1°C.


T-213-01 / V 1 EMS_Doc-v1.0.doc

Page 29 of 50

5 Implementation

5.1 Server implementation

5.1.1 GUI

The presented GUI is considered as a fast prototype. We implemented this GUI only to show that the implemented parts in the EMS application work. Implementing a nice and proper GUI needs much more time and was not part of this proof of concept.

5.1.1.1 General application GUI

Figure 11: GUI of the server application

We adopted the GUI from Robin project in its general view but adapted it according to the requirements of the EMS. Adjustments:

• More rooms are active in the KUI System

• There are 2 tabs, one for each floor (to make it easier to implement, both floors have the same floorplan)

• In the tree view just the name of the entity is shown

• A section where the current contexts of a person are shown. The background color of this section changes according to the situation of elderly person

• Different symbol for the elderly person and the medical staff


T-213-01 / V 1 EMS_Doc-v1.0.doc

Page 30 of 50

In the GUI there are 3 sections:

• Section1: Map section where the position of the persons is graphically shown on the floor plan.

• Section 2: Tree view of the positions. In this section the users see the actual position of the persons in a tree view.

• Section 3: Context View. In this section the user gets the actual context information (Temperature) and the Activity. Also the situation is shown as text and also as background color (Green � situation normal, orange � situation potentially dangerous, red �critical)

5.1.1.2 Managing elderly person

There is also a rudimental GUI in Wizard style implemented for managing (that means add, modify and delete) elderly persons. This GUI is just implemented to show that it will work; a proper GUI was not in the scope of this master thesis work.

5.1.1.2.1 Add new elderly person

Add new elderly Person Wizzard

Figure 12: Add new elderly person mask

In the mask Figure 12: Add new elderly person mask the system administrator can enter the surname, first name and the patient number of the new elderly person. The patient number must be unique in the system and is checked here. If the patient number already exists, the system administrator gets a message.


T-213-01 / V 1 EMS_Doc-v1.0.doc

Page 31 of 50

Add person of trust

Figure 13: Add person of trust mask

In this mask Figure 13: Add person of trust mask the system administrator can allocate persons of trust to this new elderly person. All medical staff set up in the system is shown. Person of trust could be added or removed Add new safe location

Figure 14: Add new safe location mask

In the mask Figure 14: Add new safe location mask the system administrator can add a new safe location and the time span during which this location is a safe place.


T-213-01 / V 1 EMS_Doc-v1.0.doc

Page 32 of 50

5.1.1.2.2 Modify elderly person

Modify elderly person

Figure 15: Modify elderly person mask

In the mask Figure 15: Modify elderly person mask the system administrator can modify all in the system available elderly person. By selecting the name on the left hand side the surname, first name and patient number is shown on the right hand side. There the system admin can change these items. By pressing Apply or Next the patient number is checked for its uniqueness in the system. Add person of trust See 5.1.1.2.1 Add new elderly person � Add person of trust Add new safe location See 5.1.1.2.1 Add new elderly person � Add new safe location Delete elderly person

Figure 16: Delete elderly person mask

In the mask Figure 16: Delete elderly person mask the system administrator can select an elderly person and then delete it by pressing the Delete button.


T-213-01 / V 1 EMS_Doc-v1.0.doc

Page 33 of 50

5.1.1.3 Manage medical staff

There is also a rudimentary GUI in Wizard style implemented for managing (i.e. add, modify and delete) medical staff. This GUI is just implemented as a proof of concept; a proper GUI was not in the scope of this master thesis work.

5.1.1.3.1 Add new medical staff

Add new medical staff Wizard

Figure 17: Add new medical staff mask

In the mask Figure 17: Add new medical staff mask the system administrator can enter the name, first name and the patient number of the new medical staff. The personal number must be unique in the system and is checked here. If the personal number already exists, the system administrator gets a message. Modify medical staff

Figure 18: Modify medical staff mask

In the mask Figure 18: Modify medical staff mask the system administrator can modify all in the system available medical staff. By selecting the name on the left hand side, the name, first name and personal number are shown on the right hand side. These items can be changed by the system administrator. By pressing Apply or Finish the patient number is checked for its uniqueness in the system.


T-213-01 / V 1 EMS_Doc-v1.0.doc

Page 34 of 50

Delete medical staff

Figure 19: Delete Medical staff mask

In the mask Figure 19: Delete Medical staff mask the system administrator can select a medical staff and then delete it by pressing the Delete button.


T-213-01 / V 1 EMS_Doc-v1.0.doc

Page 35 of 50

5.1.2 Class diagram

Figure 20: Class Diagram SBA


T-213-01 / V 1 EMS_Doc-v1.0.doc

Page 36 of 50

5.1.3 Class description

This section describes the functionality of each section. The methods are described in the source code with java doc.

5.1.3.1 EMSMain

The EMSMain class is the entry point of the server based application. It initializes the uMove (e-space, observer, views, connects activityManager and situationManager with the uMove, starts the SmartEnvironment) and also the GUI and the entity tracker.

5.1.3.2 Person

Abstract class of a person. It is just a data class including name, prename and location.

5.1.3.3 MedicalStaff

Data class of medical staff. This class includes only data of a specific medical staff.

5.1.3.4 ElderPerson

Data class of elderly person. This class includes only data of a specific elderly person.

5.1.3.5 Location

Data class of a location. This class is just used for converting location out of the xml into the uMove e-space. But there was no time to implement the xml reader for the locations.

5.1.3.6 SafeLocation

Data class of safe location. An instance of this class represents a safe location with its start and end time for an elderly person

5.1.3.7 XMLReader

This class provides a method to read back data from elderly persons and medical staffs out of the config xml-file.

5.1.3.8 EntityTracker

The entity tracker tracks all persons and alarms persons of trust, when an elderly person is in a dangerous or critical situation

5.1.3.9 EMSSituationManager

This class provides methods to check the situation of entities when a context or activity changes

5.1.3.10 TimedActivity

This class is a container for the an activity including a timestamp.

5.1.3.11 GUI classes

Only the business logic classes are described here, but not the GUI classes. Of course there is also a GUI implemented but because of the fast prototype style of the GUI it makes no sense to describe it here detailed.


T-213-01 / V 1 EMS_Doc-v1.0.doc

Page 37 of 50

5.1.4 Implementing uMove

Figure 21: Overview of the uMove System

As shown in the Figure 21: Overview of the uMove System there are different layer in the uMove system.

5.1.4.1 Entity layer

e-Space For setting up this KUI System, we first define the e-Space. The e-Space represents entity populating the “world” of the application with all the locations and also the persons inside this world. In this prove of concept, the KUI System is represented by a tree of places described in the Figure 22: Implemented e-Space.

��C�

��

!��D�

"

!��D�

#

B"$" B"$# B"$% B"$& B"$' B#$" B#$# B#$%

Figure 22: Implemented e-Space

In this advanced prototype the e-space is hard coded because there was no time left to write an xml parser which allocates this location tree. The hard part of this is that every node needs to know its parent. In the future a XML parser would make the life easier.


T-213-01 / V 1 EMS_Doc-v1.0.doc

Page 38 of 50

Activity manager The activity manager interface belongs to the uMove2 framework but it is adapted for every different application. Each application processes different kind of activities and the programmer implements specific algorithms (classes). The specific activity manager is then attached to the actors (person) who have their activities monitored. In the SBA, the default activity management is used because the MAEP has its own activity manager and the medical staff did not use the activity manager because there the user manually changes his activity by using the GUI of their application.

Relation manager The relation manager is not used in this project

5.1.5 Observation layer

5.1.5.1 View

A view is a focus on the situation and it is represented by viewers that filter on the KUI system.

uMove allows to create different viewers of the e-Space and the programmer has to define the rootEntity and also the level of deepness for the view. In the EMS Application, only one viewer was created: Viewer v1 = kuiSystem.createViewer(city, 4); We have a viewer with the root entity City and with the deepness of 4 which means that it covers the whole defined e-Space.

5.1.5.2 Observer

An observer observes the entities through the attached viewer and every time something changes at the e-space level, the observer receives an event and checks the new situation of the actor who has changed. A situation manager is attached to the observer and processes, like the activity manager does at the actor level, the actor’s contexts and activity. The result of the situation manager is sent back to the observer which then sends it to the attached application. An observer is created like this: Observer o1 = kuiSystem.createObserver(v1, emsSituationManager, new ObserverMessageProcessor());

5.1.5.3 Situation manager

The situation manager is like the activity manager part of the uMove framework but it has been adapted for every application. The State diagram of the situation manager of an elderly person is shown in Figure 24: State Diagram of the situation manager for elderly person.

Figure 23: Schematic of a view


T-213-01 / V 1 EMS_Doc-v1.0.doc

Page 39 of 50

Figure 24: State Diagram of the situation manager for elderly person

The State diagram of the medical staff is easier:

Figure 25: State diagram of the medical staff


T-213-01 / V 1 EMS_Doc-v1.0.doc

Page 40 of 50

5.1.6 Communication between Server and mobile app

Figure 26: System overview

As seen in Figure 26: System overview, the communication between SBA and mobile devices is provided by uMove. For the SBA, the mobile entity is seen as a local entity as well as the sensors in the mobile phone. This part of uMove needs no additional implementation by the programmer.

5.1.7 SendDangerousMessage

As in 4.2.1.1 Send Dangerous Message described, the geographical next person of trust will be alarmed. In the application it is implemented like this:

Figure 27: Example of an e-space

If EP1 is in a dangerous situation the sendDangerousMessage method is called. 1 Ask for parent of EP1 �A303 2 Ask for parent of parent of EP1 � parent of A303 �Floor3 3 Ask for structure of parent of parent of EP1 �Structure of Floor3 � [A303, A304, A305, A306, A307] 4 Ask for every person in a room of the Floor3s Structure � in A303 only EP1 4.1 Check if person is a medical staff �EP1 is a resident 4.2 If person is a medical staff, calculate distance vector 5 Repeat step 4 for all rooms from step 4 In this example the MS1 is nearer than the MS2. MS3 is on another floor, so he will not be checked. In this case the application will alarm the medical staff MS1


T-213-01 / V 1 EMS_Doc-v1.0.doc

Page 41 of 50

For the current nearest person of trust and for every other person of trust which is available the distance vector will be calculated. Every room knows its spatial coordinate of the room middle so the distance vector is calculated

longDifCurrent = |currentNearestPOTLongitude – elderPersonLongitude|

Formula 3: Difference of longitude

latitudeDifCurrent = |currentNearestPOTLatitude – elderPersonLatitude|

Formula 4: Difference of latitude

Formula 5: DistanceVector

The distance vector of the current person of trust is calculated in the same way like the distance vector of the current nearest person of trust. In this case the server application alarms the geographical next person of trust, but this is not necessarily the medical staff within the shortest distance to the elderly person. In a further application this algorithm has to be improved.

5.1.1 SendCriticalMessage

As in 4.2.1.2 SendCriticalMessage Design described, all persons of trust on the same floor will be alarmed. So there is no need to calculate a distance vector like in 5.1.7 SendDangerousMessage. The remaining alarming procedure is the same as in SendDangerousMessage.


T-213-01 / V 1 EMS_Doc-v1.0.doc

Page 42 of 50

5.1.2 XML Parser

We implemented the XML-parser as it helps a lot for testing the advanced prototype. So the programmer is able to modify the data of the medical staff and also the elderly person. In the actual version the implemented XML-parser checks the XML-file against the XML schema.

Listening 3: config.xml versus schema check

First we create a new instance of the schema factory and there we read in the config xsd schema. For validating there is also a validator needed. After that the config.xml must be read, parsed and validated with the generated validator. If the validation doesn’t pass, an exception will be thrown. If the XML File passes the validation, the parser first reads all medical staff and stores them in the medicalStaff vector. When all medical staff is read, the parser makes the same procedure with the elderly person.

try { //create a new instance of a schema factory SchemaFactory schemaFactory = SchemaFactory.newInstance(XMLConstants.W3C_XML_SCHEMA_NS_URI); //create the xsd shema Schema xsdSchema = schemaFactory.newSchema(new File("C:\\EMS\\ServerKUIApplication\\src\\app\\config.xsd")); //create a new validator Validator validator = xsdSchema.newValidator(); //create a new instance of a doc builder factory DocumentBuilderFactory docBuilderFactory = DocumentBuilderFactory.newInstance(); //create a new doc builder DocumentBuilder docBuilder = docBuilderFactory.newDocumentBuilder(); //read in the config file File configFile = new File("C:\\EMS\\ServerKUIApplication\\src\\app\\config.xml"); //parse the config file Document doc = docBuilder.parse(configFile); //validate the config file validator.validate(new DOMSource(doc)); … } catch (SAXParseException err) { System.out.println("** Parsing error" + ", line " + err.getLineNumber() + ", uri " + err.getSystemId()); System.out.println(" " + err.getMessage()); } catch (SAXException e) { Exception x = e.getException(); ((x == null) ? e : x).printStackTrace(); }


T-213-01 / V 1 EMS_Doc-v1.0.doc

Page 43 of 50

5.2 Mobile Application for elderly person

5.2.1 Class diagram

Figure 28: Class diagram of the MAEP


T-213-01 / V 1 EMS_Doc-v1.0.doc

Page 44 of 50


This section describes what every class does. The methods are described in the source code with java doc.

5.2.2.1 Main Activity

The Mainactivity class is the entry point of the mobile application. It initializes the GUI, the AndroidMobile class, the Bluetooth location tracking. This activity is also responsible for updating the GUI.

5.2.2.2 SettingsForm

This activity allows the System administrator to change the name of the elderly person via the mobile application GUI. After a name change the application must be restarted.

5.2.2.3 AndroidMobile

This class is the connectivity class between the mobile device and the server based application. It also set up the mobile e-space of the uMove framework.

5.2.2.4 DiscoveryService

This is the object that receives interactions from clients. See RemoteService for a more complete example.

5.2.2.5 DiscoveryBinder

Class for clients to access. Because we know this service always runs in same process as its clients, we don't need to deal with inter-process communication.

5.2.2.6 RemoteBTDevice

Data class for the found Bluetooth devices

5.2.2.7 AndroidTempSensor

Creates a uMove sensor out of the physical temperature sensor from Android.

5.2.2.8 AndroidAccSensor

Creates a uMove sensor out of the physical accelerometer sensor from Android.

5.2.2.9 MobileActivityManager

Activity manager of the mobile device owner. Convert the actual motion in an activity.

5.2.2.10 MobileSituationManager

Situation manager of the mobile device owner. Will not have any logic because we implemented the situation manager on the server side

5.2.2.11 UnknownLocationTagProcessor

Generates a message with the MessageTye SENSOR_UNKNOWN_LOCATIONTAG_CHANGED

5.2.2.12 MobileActivitySengetMessageProcessor

Just checks if the message is not null and an instance of KUI Message


T-213-01 / V 1 EMS_Doc-v1.0.doc

Page 45 of 50

5.2.3 Location Tracking

According to the need of the mobile entities localization, the location tracking was a big issue in this master thesis. At the beginning, the idea of a location tracking using Bluetooth, Wireless LAN or RFID were taken into consideration. We decided to implement a Bluetooth solution for detecting the location based on a solution provided by PAI Group. The same location tracking will be used in the MAEP and also in the MAMS.

5.2.3.1 Bluetooth Location Tracking

The idea of Bluetooth location tracking is to check all available known Bluetooth devices in the area. It checks the received signal strength indicator and decides in which room the person is in. The known Bluetooth device with the strongest RSSI is considered to be the nearest one and it is then possible to infer in which room the mobile phone is located.

5.2.3.1.1 Problems with Bluetooth in Android

It is extremely clumsy and takes a lot of battery power to read the RSSI of a Bluetooth device with the current implementation of the Bluetooth API (Android 2.0) from Google. In contrast to the Bluetooth Spec, Google’s Android Bluetooth API allows just to read the RSSI during the device discovery. Every time the application checks the location, a new Bluetooth discovery has to be done. This also needs a lot of time (can be more than 20 sec for the whole discovery process)

5.2.3.1.2 Sequence diagram of the Bluetooth Service

Figure 29: Sequence diagram Bluetooth service in the mobile Android application.

As the figure 12 shows, when the MainActivity is created, the discoveryService is initialized with the DiscoveryServiceManager as the service Listener. During the initialization of the blueChannel the DiscoveryService is started. The discoveryService searches automatically all available Bluetooth devices in range, connects to each and measures the RSSI value and stores the Bluetooth-ID and the measured RSSI in a set. After the discovery has finished the service calls the onDiscoveryFinished method of the DiscoveryServiceManager. This


T-213-01 / V 1 EMS_Doc-v1.0.doc

Page 46 of 50

method searches the Bluetooth device with the strongest RSSI and transforms the Bluetooth–ID in a location name and calls the changeLocation method of the connection class AndroidMobile which sends the location change to the server.

5.2.3.1.3 Setting up “location indicators”

Location indicators are devices which sends out their Bluetooth Ids to show the name of the room. So a location indicator will be accepted as an location indicator, the Bluetooth ID of this device (e.g. mobile phone) has to be set up in the following form: Ems_<room_name> e.g. for the room A307 following Bluetooth ID has to be set: Ems_A307. The prefix “Ems_” is used to evaluate if this received Bluetooth ID contains to the elderly monitoring system. So other active Bluetooth devices will not disturb the location tracking.

5.2.3.1.4 Test

A short performance test was done to check if this location tracking algorithm works like it should:

Test description Hopping 10 times from the room with location indicator Ems_A303 to the room with indicator Ems_A307 and measure the time until the person change location in the application.

Results

Hopping direction Time until location change [s] A303 � A307 18 A307 � A303 23 A303 � A307 18 A307 � A303 20 A303 � A307 20 A307 � A303 38 A303 � A307 17 A307 � A303 20 A303 � A307 14 A307 � A303 13

Due to this test we can say that the detection of a location change has a resolution better than 1 minute.

5.2.3.1.5 Improvement

It would be better to send the whole set of visible Bluetooth Devices to the server and then implement the location detection heuristic on the server side in order to use a bigger available CPU power. Also every additional calculation on the mobile device needs power battery capacity, which is still limited. In this study, it was defined that there is no need to pay attention to the power consumption, but in a market-ready product it will be a very critical point.

5.2.3.2 Possible alternatives

Due to the implementation of Google’s Bluetooth API in Android 2.0, for a market-ready product another location tracking strategy must be found.


T-213-01 / V 1 EMS_Doc-v1.0.doc

Page 47 of 50

5.2.3.2.1 RFID

The location tracking with RFID is not that useful because the people (elderly person and medical staff) always have to confirm their location change via an RFID reader which will be installed nearby the doors due to the closed distances between the tag and the reader. It’s not possible to read out the tag just on the fly. Also, the infrastructure needs to be adapted and a big cabling in the whole building will be necessary. Positive Negative No power needed from mobile phone People have to confirm the location change by

pressing their tag on the reader � easy to forget Only location change message when the location really changed

huge cabling in the whole building � very expensive

5.2.3.2.2 Wireless LAN

Wireless LAN could be a really interesting alternative. But for reliable location detection, a lot of access points are needed. There exists a project called Redpin from the University of Zurich. Redpin is an open source indoor positioning system that was developed with the goal of providing at least room-level accuracy. For a further development, it may be useful to check this project. Of course, the source code of the Redpin has to be adapted for the EMS. Therefore I decided to just describe Redpin as an alternative to the implemented Bluetooth location tracking, without making any tests with it due to the limited time and setting the priorities on the subject itself. Positive Negative Accurate location tracking WLAN needs also a lot of power, but less than

the implemented Bluetooth solution A open source project from ETH Zurich is available

medium cabling in the whole building because of the access points� expensive

Needs a lot of time to adapt the Redpin source Documentation of the Redpin


T-213-01 / V 1 EMS_Doc-v1.0.doc

Page 48 of 50

5.3 Mobile application for medical staff

5.3.1 Class diagram

Figure 30: Class diagram of the MAMS


T-213-01 / V 1 EMS_Doc-v1.0.doc

Page 49 of 50


This section describes the functionality of every class. The methods are described in the source code with java doc.

5.3.2.1 MainActivity

See 5.3.2.1 MainActivity

5.3.2.2 SettingsForm

See 5.3.2.2 SettingsForm

5.3.2.3 AlarmMessageBox

A class to generate an alarm message box to show the alarm text receiving from server based application.

5.3.2.4 AndroidMobile

See 5.3.2.4 AndroidMobile

5.3.2.5 Continuous alarm task

A class which is used for the continuous alarm earcon.

5.3.2.6 Babel

A class to send a phrase to the text-to-speech plugin. It controls the acoustic output.

5.3.2.7 LocalizedString

A class which combines the language and the content. Used for the text-to-speech plugin

5.3.2.8 DiscoveryService

See 5.2.2.4 DiscoveryService

5.3.2.9 DiscoveryBinder

See 5.2.2.5 DiscoveryBinder

5.3.2.10 RemoteBTDevice

See 5.2.2.6 RemoteBTDevice

5.3.2.11 MobileActivityManager

Activity manager of the mobile device owner.

5.3.2.12 MobileSituationManager

See 5.2.2.10 MobileSituationManager

5.3.2.13 UnknownLocationTagProcessor

See 5.2.2.11 UnknownLocationTagProcessor

5.3.2.14 MobileActivitySengetMessageProcessor

See 5.2.2.12 MobileActivitySengetMessageProcessor


T-213-01 / V 1 EMS_Doc-v1.0.doc

Page 50 of 50

5.3.3 Location tracking

The location tracking works same as the location tracking for the elderly person. See 5.2.3 Location Tracking

5.3.4 Text to speech

Text to speech is an engine that converts strings to voice. This tool is available in the Android market and have to be downloaded before using. The TTS supports a number of languages: English, French, German, Italian and Spanish. Also American and British accents for English are both supported. In this application only British English will be used. A good description of the TTS can be found on : http://android-developers.blogspot.com/2009/09/introduction-to-text-to-speech-in.html When the medical staff application receives an alarm message through the alarm service the app differs if the alarm message is a dangerous message or a critical message. If the message contains dangerous the whole message will be converted to voice and is played as an earcon. If the message contains critical a continuous alarm task will be started which sends every 5 seconds a new alarm message to be converted from text to speech as an continuous earcon.

T-213-10 / V 1 EMS_Software_Test_Instructions-v1.0.doc

Page 1 of 36

f

Process:

Software Test Instruction and Report


Number MT-10-01.14

Version: 1.0


Template: T-213-10 Software TIR




Postfach 325, CH-3000 Bern 22, [email protected], +41 31 84 83 272 Keywords uMove, elderly person, monitoring, KUI, kinetic user interface

Release



Software Test Instruction and Report Version 1.0


Page 2 of 36

1� Introduction 3�

1.1� Purpose .............................................................................................................................. 3�

2� System requirements 4�2.1.1� System interfaces .......................................................................................................... 4�2.1.2� User interface ................................................................................................................ 5�

2.1.2.1� Server based application .................................................................... 5�2.1.2.2� Mobile application .............................................................................. 6�

2.1.3� Hardware Interface ........................................................................................................ 6�2.1.4� Software interface ......................................................................................................... 7�

3� Specific Software Requirements for server based application 8�

3.1� General............................................................................................................................... 8�

3.2� Set up the system ............................................................................................................... 9�

3.3� Check condition of elderly person ..................................................................................... 12�

3.4� Receive location ............................................................................................................... 14�

3.5� Appraise situation ............................................................................................................. 15�

3.6� Alarm escalation ............................................................................................................... 16�

3.7� Alarming medical staff ...................................................................................................... 18�

3.8� Confirm alarm ................................................................................................................... 20�

4� Specific Software Requirements for elderly person mobile application 21�

4.1� General............................................................................................................................. 21�

4.2� Analysis of activity ............................................................................................................ 22�

4.3� Check temperature ........................................................................................................... 23�

4.4� Check location .................................................................................................................. 24�

4.5� Send context changes ...................................................................................................... 25�

4.6� Alarming ........................................................................................................................... 26�

4.7� Usage of the mobile app ................................................................................................... 26�

5� Mobile application for medical staff requirements 28�

5.1� General............................................................................................................................. 28�

5.2� Alarming ........................................................................................................................... 29�

5.3� Confirm alarm ................................................................................................................... 30�

5.4� Change situation ............................................................................................................... 31�

5.5� Check location .................................................................................................................. 32�

5.6� Send context changes ...................................................................................................... 34�

5.7� Usage of the mobile app ................................................................................................... 34�

6� Documentation 35�

7� Test result summary 36�

8� Document history 36�



Page 3 of 36

1 Introduction

1.1 Purpose

This document shows which points of the software requirement specification are implemented and where is a discrepancy between specification and implementation. In this document all 3 parts of the elderly monitoring system are tested against the spec.



Page 4 of 36

2 System requirements

Req. ID Ch. Module Brief test description Status

(OK/NOK) Comment

SWRS-SYS-01

2.7 System Verify that the application has implemented a KUI system OK -

Test Nr.

Ref. Nr.

Test Procedure Expected Result OK/ NOK

Attachment

Test 1

1.1 Check if the application has implemented a KUI system. KUI system used OK -

Remarks

uMove is used KUI system

2.1.1 System interfaces


(OK/NOK) Comment

SWRS-SYS-02

2.7.1 System Verify that the System does not interact with other systems. There is only one server based application and one or more mobile applications for elderly persons and one or more applications for medical staff

OK

Test Nr.

Ref. Nr.


Attachment

Test 1

1.1 Check if the system does not interact with other systems.

One system is used as a server based application

OK



Page 5 of 36

Test Nr.

Ref. Nr.


Attachment

1.2 Check if the system is running with one or more mobile applications for elderly persons.

System runs with one to four mobile applications for elderly persons.

OK

1.3 Check if the system is running with one or more mobile applications for medical staff

System runs with one to four mobile applications for medical staff.

OK

Remarks

Due to the fact that only two Motorola Milestone mobile phones were available the test was made with a mobile phone simulator

2.1.2 User interface

2.1.2.1 Server based application


(OK/NOK) Comment

SWRS-SYS-03

2.7.2.1 System Verify that the user has the following Interfaces to interact with the server based EMS application:

- Screen

- Keyboard

- Mouse

OK -

Test Nr.

Ref. Nr.


Attachment

Test 1

1.1 Check if interaction with Mouse of the server based EMS application is visible on Screen.

Server based EMS application is operable with Screen and Mouse.

OK

1.2 Check if interaction with Keyboard of the server based EMS application is visible on Screen.

Server based EMS application is operable with Screen and Keyboard.

OK



Page 6 of 36

Test Nr.

Ref. Nr.


Attachment

Remarks

2.1.2.2 Mobile application

Req. ID Ch. Module Brief test description Status (OK/NOK)

Comment

SWRS-SYS-04

2.7.2.2 System Verify that the user has the following Interfaces to interact with the mobile EMS application:

- Touchscreen

OK

Test Nr.

Ref. Nr.


Attachment

Test 1

1.1 Check if interaction with Touchscreen on the mobile EMS application is visible on Screen.

Mobile EMS application is operable with Touchscreen

OK

Remarks

2.1.3 Hardware Interface


Comment

SWRS-SYS-05

2.7.3 System Verify that the PAI Group of the University of Fribourg allocated at least one mobile device with Android Operation system

OK

Test Nr.

Ref. Nr.


Attachment

Test 1



Page 7 of 36

Test Nr.

Ref. Nr.


Attachment

1.1 Check if the PAI Group of the University of Fribourg allocated one mobile device with Android Operation system.

One mobile device with Android Operation system is available.

OK

Remarks

2.1.4 Software interface


Comment

SWRS-SYS-06

2.7.4 System Verify that the application uses the uMove library. OK

Test Nr.

Ref. Nr.


Attachment

Test 1

1.1 Check if the application uses the uMove library. uMove library is included and functions are used.

OK

Remarks



Page 8 of 36

3 Specific Software Requirements for server based application

3.1 General Req. ID Ch. Module Brief test description Status

(OK/NOK) Comment

SWRS- GEN-01

3.1 server based application

Verify that the application is as modular as possible in order to be able to change modules without the need of rewriting the code

OK

Test Nr.

Ref. Nr.


Attachment

Test 1

1.1 Check if the application is structured as modular as possible.

server based application is structured in different modules according its tasks and functionality.

OK SBA_ClassDiagram.pdf

Remarks


(OK/NOK) Comment

SWRS- GEN-02

3.1 server based application

Verify that the applications are clearly implemented and documented/commented in order to be extended and reused in other projects

OK

Test Nr.

Ref. Nr.


Attachment

Test 1

1.1 Check if the application code is documented/commented.

Design Description matches with code and comments in code are existing.

OK



Page 9 of 36

Test Nr.

Ref. Nr.


Attachment

Remarks

The classes are described in the software description and the methods are described as JavaDoc in the code

3.2 Set up the system

uMove is designed to autonomously discover new mobile devices with uMove running on it. So, any person carrying a uMove enabled device (elderly persons or medical staff) will be discovered and managed automatically by the uMove framework when they enter the building. In the setup the system administrator is able to modify system attributes. Req. ID Ch. Module Brief test description Status

(OK/NOK) Comment

SWRS- SUP-01

3.2 system Verify that it’s possible to define different safe locations for every elderly person in the system depending on time and date

OK

Test Nr.

Ref. Nr.


Attachment

Test 1

1.1 Define different safe locations for every elderly person in the system depending on time and date.

Safe locations for every elderly person changes depending on defined time and date.

OK

Remarks

Safe Locations could be set through the GUI and the main configuration should be made in the config XML


(OK/NOK) Comment

SWRS- SUP-02

3.2 system Verify that it’s possible to modify safe locations (position, time, date) for every elderly person in the system

OK



Page 10 of 36

Test Nr.

Ref. Nr.


Attachment

Test 1

1.1 Modify safe locations (position, time, date) for every elderly person in the system.

Safe locations for every elderly person can be modified.

OK

Remarks

Safe Locations can be modified through the GUI and also through the config XML


(OK/NOK) Comment

SWRS- SUP-03

3.2 system Verify that it’s possible to define persons of trust for every elderly person.

OK

Test Nr.

Ref. Nr.


Attachment

Test 1

1.1 Define persons of trust for every elderly person. Persons of trust for every elderly person can be defined.

Remarks

Persons of trust can be set by the GUI and the main configuration should be made in the config XML


(OK/NOK) Comment

SWRS- SUP-04

3.2 system Verify that it’s possible to modify persons of trust for every elderly person.

OK

Test Nr.

Ref. Nr.


Attachment

Test 1

1.1 Modify persons of trust for every elderly person Persons of trust for every elderly person can be modified.

OK



Page 11 of 36

Test Nr.

Ref. Nr.


Attachment

Remarks

Persons of trust can be modify through the GUI and also through the config XML


(OK/NOK) Comment

SWRS- SUP-05

3.2 system Verify that it’s possible to assign a specified Bluetooth ID to a room.

NOK The Bluetooth ID just can be set in the source code

Test Nr.

Ref. Nr.


Attachment

Test 1

1.1 Assign a specified Bluetooth ID to each room.. Specified Bluetooth ID to each room can be assigned.

NOK

Remarks

Due to the GUI implementing taking a lot of time, the decision was to focus on the uMove parts.


(OK/NOK) Comment

SWRS- SUP-06

3.2 system Verify that it’s possible to modify the assigned Bluetooth ID to a room.

NOK

Test Nr.

Ref. Nr.


Attachment

Test 1

1.1 Modify the assigned Bluetooth ID to each room. Assigned Bluetooth ID to each room can be modified.

NOK

Remarks

Due to the GUI implementing taking a lot of time, the decision was to focus on the uMove parts.



Page 12 of 36

3.3 Check condition of elderly person


(OK/NOK) Comment

SWRS- CHC -01

3.3 Elder Person

Verify that it’s possible for medical staff to find the actual location of a defined elderly person by position of Floor No. and Room No.

OK

Test Nr.

Ref. Nr.


Attachment

Test 1

1.1 Log in as medical staff and check actual location of all elderly person by position of Floor No. and Room No.

All elderly persons are found by position of Floor No. and Room No.

OK

Remarks


(OK/NOK) Comment

SWRS- CHC -02

3.3 Elder Person

Verify that in the floor plan view is a tab for every floor. OK

Test Nr.

Ref. Nr.


Attachment

Test 1

1.1 Check if in the floor plan view is a tab for every floor. Every floor is accessible by its own tab OK

Remarks

2 floors are implemented


(OK/NOK) Comment



Page 13 of 36


Comment

SWRS- CHC -03

3.3 Elder Person

Verify that in the floor plan view the elderly person is defined as a point in the room including the first and last name.

OK

Test Nr.

Ref. Nr.


Attachment

Test 1

1.1 Check if in the floor plan view all elderly persons are defined as a point in the room including first and last name.

Every floor is found with a point in the room including first and last name.

OK

Remarks

The entity name in the form EP_<patient_number> is shown. But the elderly person is shown as an icon including his status. Due to changes in GUI taking a lot of time, the decision was to focus on the uMove parts.


(OK/NOK) Comment

SWRS- CHC -04

3.3 Tree view Verify that in the tree view every floor has its own tree like shown in Ch. 3.2 figure 2: Tree view.

OK

Test Nr.

Ref. Nr.


Attachment

Test 1

1.1 Check if in the tree view every floor has its own tree like shown in Ch. 3.2 figure 2: Tree view.

There is a tree view over the whole e-space

OK

Remarks


(OK/NOK) Comment

SWRS- CHC -05

3.3 Tree view Verify that in the tree view elderly person are defined as an entry containing the first and last name.

OK



Page 14 of 36

Test Nr.

Ref. Nr.


Attachment

Test 1

1.1 Check if in the tree view elderly person are defined as an entry containing the First and Last name.

Every elderly person is found as an entry with First and Last name..

OK

Remarks

Only the entity name in the form EP_<patient_number> is shown. Due to changes in GUI taking a lot of time, the decision was to focus on the uMove parts.


(OK/NOK) Comment

SWRS- CHC -06

3.3 Tree view Verify that on clicking on the elderly person in the GUI the medical staff gets information about the elderly person such as actual location, actual activity, Actual context (temperature) and actual situation (normal, dangerous, critical)

OK

Test Nr.

Ref. Nr.


Attachment

Test 1

1.1 Click on every elderly person in the GUI as medical staff and get information about the elderly person.

For every elderly person information is found like actual location, actual activity, actual context (temperature) and actual situation (normal, dangerous, critical)

OK

Remarks

Pressing on the elderly person in the tree view, the context and activity information are shown in the GUI

3.4 Receive location


(OK/NOK) Comment



Page 15 of 36


Comment

SWRS- REL-01

3.4 SBA Verify that the SBA translates the received Bluetooth-ID into a room number

NOK

Test Nr.

Ref. Nr.


Attachment

Test 1

1.1 Send Bluetooth-IDs to the SBA and check if they’re translated to a room number.

For every received Bluetooth-ID must exist a room number.

OK

Remarks

There was a concept change: the mobile application converts the Bluetooth ID in a room name and sends a location change message to the SBA.

3.5 Appraise situation


(OK/NOK) Comment

SWRS- -APS-01

3.6 SBA Verify that the SBA decide in which situation (Normal, Dangerous, Critical) the elderly person is according to the Table 1: in Chapter 3.6 Situation of certain elderly person

OK

Test Nr.

Ref. Nr.


Attachment

Test 1

1.1 Send activities and contexts of the elderly person to the SBA and check if the correct situation is set.

For every current activity and the contexts of the elderly person the SBA sets the correct situation.

OK



Page 16 of 36

Test Nr.

Ref. Nr.


Attachment

Remarks

3.6 Alarm escalation


(OK/NOK) Comment

SWRS-ALE-01

3.7 SBA Verify that if an elderly person is in a dangerous situation the SBA alarms the nearest available person of trust

OK

Test Nr.

Ref. Nr.


Attachment

Test 1

1.1 Set an elderly person in a dangerous situation and check if the SBA alarms the nearest available person of trust.

The SBA sets the alarm to the nearest available person of trust for an elderly person in a dangerous situation.

OK

Remarks


(OK/NOK) Comment

SWRS-ALE-02

3.7 SBA Verify that if an elderly person is in a critical situation the SBA warns all available persons of trust on the same floor.

OK

Test Nr.

Ref. Nr.


Attachment

Test 1



Page 17 of 36

Test Nr.

Ref. Nr.


Attachment

1.1 Set an elderly person in a dangerous or critical situation and check if the SBA warns all available persons of trust with on the same floor.

The SBA warns all available persons of trust on the same floor for an elderly person in a dangerous situation.

OK

Remarks


(OK/NOK) Comment

SWRS-ALE-03

3.7 SBA Verify that if an elderly person is in a critical situation the SBA alarms the all available person of trust on the same floor.

OK

Test Nr.

Ref. Nr.


Attachment

Test 1

1.1 Set an elderly person in a critical situation and check if the SBA alarms all available person of trust on the same floor.

The SBA alarms all available person of trust for an elderly person on the same floor

OK

Remarks


(OK/NOK) Comment

SWRS-ALE-04

3.7 SBA Verify that if the person of trust doesn’t confirm the alarm message within 1 minute the SBA alarms any nearest person of trust.

NOK

Test Nr.

Ref. Nr.


Attachment

Test 1

1.1 Send an alarm to a person of trust and don’t confirm it. The SBA sets the alarm any nearest person of trust after 1 minute.

NOK



Page 18 of 36

Test Nr.

Ref. Nr.


Attachment

Remarks

This feature has priority 3 (proposition) so due to the time it is not implemented.


(OK/NOK) Comment

SWRS-ALE-05

3.7 SBA Verify that the alarming time interval can be set by the system administrator.

NOK

Test Nr.

Ref. Nr.


Attachment

Test 1

1.1 Log in as administrator and change the alarming time interval. Send an alarm to a person of trust and don’t confirm it.

The SBA sets the alarm any nearest person of trust after the new alarming time interval.

NOK

Remarks


3.7 Alarming medical staff


(OK/NOK) Comment

SWRS- ANS -01

3.8 SBA Verify that the SBA pops up a window on the screen with an alarm message.

NOK

Test Nr.

Ref. Nr.


Attachment

Test 1



Page 19 of 36

Test Nr.

Ref. Nr.


Attachment

1.1 Send an alarm and check if a pop up a window on the screen with an alarm message appears.

A pop up a window on the screen with an alarm message appears.

NOK

Remarks

There is no pop up which shows the alarm but the background color of the user details change from green (normal) to orange (dangerous) to red (critical).


(OK/NOK) Comment

SWRS- ANS -02

3.8 SBA Verify that the SBA sends a message with the alarm to the mobile device of the person defined for the chosen escalation scenario.

OK

Test Nr.

Ref. Nr.


Attachment

Test 1

1.1 Send an alarm and check if a message with the alarm to the mobile device of the person defined for the chosen escalation scenario is send.

The person defined for the chosen escalation scenario receives a message with the alarm on its the mobile device.

OK

Remarks

The scenarios dangerous and critical work ok, but there is no alarm escalation implemented


(OK/NOK) Comment

SWRS- ANS -03

3.8 SBA Verify that in the alarm message there is included the actual location, actual activity, actual context (temperature) and actual situation (normal, dangerous, critical) of the elderly person which is in a critical or dangerous situation

OK

Test Nr.

Ref. Nr.


Attachment

Test 1



Page 20 of 36

Test Nr.

Ref. Nr.


Attachment

1.1 Send an alarm and check if the message contains all information.

The alarm message contains the actual location, actual activity, actual context (temperature) and actual situation (normal, dangerous, critical) of the elderly person which is in a critical or dangerous situation

OK

Remarks

On the mobile device all user information is shown. Also in the user details in the GUI of the SBA.

3.8 Confirm alarm


(OK/NOK) Comment

SWRS- COA -01

3.9 medical staff mobile application

Verify that the medical staff is able to confirm the alarm via their mobile device.

OK

Test Nr.

Ref. Nr.


Attachment

Test 1

1.1 Send an alarm and check if the medical staff is able to confirm the alarm via their mobile device.

The medical staff is able to confirm the alarm via their mobile device.

OK

Remarks

The medical staff is able to confirm or reject the alarm by pressing a button in the GUI of his mobile application. If he accepts the alarm, this is shown in the GUI in the user details of the elderly person in dangerous or critical situation. The priority of this requirements has changed from priority3 to priority 1 during the master thesis because this shows the bidirectional communication of a service.



Page 21 of 36

4 Specific Software Requirements for elderly person mobile application

4.1 General


(OK/NOK) Comment

SWRS- GEN-01

4.1 elderly person mobile application

Verify that the application is as modular as possible in order to be able to change modules without the need of rewriting the code.

OK

Test Nr.

Ref. Nr.


Attachment

Test 1

1.1 Check if the application structured as modular as possible.

MAEP is structured in different modules according its tasks and functionality.

OK MAEP_ClassDiagram.pdf

Remarks


(OK/NOK) Comment

SWRS- GEN-02



OK

Test Nr.

Ref. Nr.


Attachment

Test 1



Page 22 of 36

Test Nr.

Ref. Nr.


Attachment


Design Description matches with code and comments in code are existing.

OK

Remarks

The classes are described in the software description and the methods are described as JavaDoc in the code

4.2 Analysis of activity

Using the data from the accelerometer the MAEP evaluates the activity of the elderly person. There are just 3 different activities to detect in this advanced prototype:

- Normal behavior - Strange behavior - Fall down


(OK/NOK) Comment

SWRS- ANA-01


Verify that the MAEP is able to read out the accelerometer of the mobile device.

OK

Test Nr.

Ref. Nr.


Attachment

Test 1

1.1 Bring the mobile device to the different states and check the read out the accelerometer with the MAEP.

The MAEP reads out the accelerometer of the mobile device according to the different states.

OK

Remarks



Page 23 of 36


Comment

SWRS- ANA-02


Verify that the MAEP is able to interpret the data from the accelerometer and decide if the elderly person has a normal behavior, has a strange behavior or falls down.

OK

Test Nr.

Ref. Nr.


Attachment

Test 1

1.1 Bring the mobile device to the different states and check if the MAEP changes the states of behavior..

The MAEP interprets the data from the accelerometer and decides if the elderly person has a normal behavior, has a strange behavior or falls down.

OK

Remarks

Only a really simple motion detection is implemented because this motion detection is the main problem of another master thesis!

4.3 Check temperature


(OK/NOK) Comment

SWRS- CHT -01


Verify that the MAEP is able to read out the temperature sensor of the mobile device

OK

Test Nr.

Ref. Nr.


Attachment

Test 1



Page 24 of 36

Test Nr.

Ref. Nr.


Attachment

1.1 Check the read out of the temperature sensor of the mobile device with the MAEP.

The MAEP reads the temperature sensor of the mobile device.

OK

Remarks

4.4 Check location


(OK/NOK) Comment

SWRS- CHL -01


Verify that the MAEP is able to receive the Bluetooth IDs of “location indicators”

OK

Test Nr.

Ref. Nr.


Attachment

Test 1

1.1 Check if the MAEP receives the Bluetooth IDs of “location indicators”

The MAEP receives the Bluetooth IDs of “location indicators”

OK

Remarks


(OK/NOK) Comment

SWRS- CHL -02


Verify that the MAEP is able to measure the RSSI of the Bluetooth “location indicators”.

OK



Page 25 of 36

Test Nr.

Ref. Nr.


Attachment

Test 1

1.1 Check if the MAEP measure the RSSI of the Bluetooth “location indicators”.

The MAEP measure the RSSI of the Bluetooth “location indicators”.

OK

Remarks


(OK/NOK) Comment

SWRS- CHL -03


Verify that the MAEP chooses the” location indicator” with the strongest RSSI with its ID saved in the SBA database.

OK

Test Nr.

Ref. Nr.


Attachment

Test 1

1.1 Go to a room with different Bluetooth “location indicators” and check if the MAEP chooses the” location indicator” with the strongest RSSI with its ID saved in the SBA database.

The MAEP has chosen the” location indicator” with the strongest RSSI with its ID and saved in the SBA database.

OK

Remarks

Concept change; all location indicators have a Bluetooth id beginning with EMS_<room_name> so the mobile application decides itself if the received Bluetooth id is a “location indicator” of the EMS





Page 26 of 36

4.6 Alarming Req. ID Ch. Module Brief test description Status

(OK/NOK) Comment

SWRS- ALA-01


Verify that the MAEP alarms the elderly person with a sound when he/she is in a dangerous or critical situation

NOK

Test Nr.

Ref. Nr.


Attachment

Test 1

1.1 Set the elderly person to dangerous or critical situation and check if the MAEP alarmed the elderly person with a sound.

The MAEP alarmed the elderly person with a sound when he/she was in a dangerous or critical situation

NOK

Remarks


4.7 Usage of the mobile app Req. ID Ch. Module Brief test description Status

(OK/NOK) Comment

SWRS- USA -01


Verify that the MAEP starts up automatically when the mobile device starts up.

NOK

Test Nr.

Ref. Nr.


Attachment

Test 1



Page 27 of 36

Test Nr.

Ref. Nr.


Attachment

1.1 Switch off the mobile device. Switch on the mobile device and check if the MAEP starts up automatically

After switching on the mobile device the MAEP started up automatically.

NOK

Remarks

The application must be started up manually. This feature has priority 2 (wish point) so due to the time it is not implemented.



Page 28 of 36

5 Mobile application for medical staff requirements

5.1 General


(OK/NOK) Comment

SWRS- GEN-01

5.1 Medical stuff mobile application

Verify that the application is as modular as possible in order to be able to change modules without the need of rewriting the code

OK

Test Nr.

Ref. Nr.


Attachment

Test 1

1.1 Check if the application is structured as modular as possible.

server based application is structured in different modules according to its tasks and functionality.

OK

Remarks


(OK/NOK) Comment

SWRS- GEN-02



OK

Test Nr.

Ref. Nr.


Attachment

Test 1


Design Description matches with code and Comments in code are existing.

OK



Page 29 of 36

Test Nr.

Ref. Nr.


Attachment

Remarks

5.2 Alarming


(OK/NOK) Comment

SWRS- ALM-01


Verify that the MAMS alarms medical staff by earcon when an elderly person is in a dangerous situation.

OK

Test Nr.

Ref. Nr.


Attachment

Test 1

1.1 Set the elderly person to a dangerous situation and check if the MAMS alarmed the medical staff by earcon.

The MAMS alarmed medical staff by earcon when an elderly person is in a dangerous situation.

OK

Remarks

The whole error text is converted from text to speech.


(OK/NOK) Comment

SWRS- ALM-02


Verify that the MAMS alarms medical staff with a continuous earcon when an elderly person is in a critical situation.

OK

Test Nr.

Ref. Nr.


Attachment



Page 30 of 36

Test Nr.

Ref. Nr.


Attachment

Test 1

1.1 Set the elderly person to critical situation and check if the MAMS alarmed the medical staff with a continuous earcon.

The MAMS alarmed medical staff with a continuous earcon when an elderly person is in a critical situation.

OK

Remarks

A continuous alarm message is converted from text to speech


(OK/NOK) Comment

SWRS- ALM-03


Verify that the MAMS shows the from SBA received information about the elderly person (Location (floor and room number), Situation, activity) on the screen

OK

Test Nr.

Ref. Nr.


Attachment

Test 1

1.1 Set the elderly person to a dangerous or critical situation and check if the MAMS shows the from SBA received information about the elderly person (Location (floor and room number), Situation, activity) on the screen

The MAMS showed the from SBA received information about the elderly person (room number, Situation) on the screen.

OK

Remarks

5.3 Confirm alarm


(OK/NOK) Comment



Page 31 of 36


Comment

SWRS- ALM-01


Verify that the MAMS allows medical staff to confirm the alarm by pressing a confirm button on the touchscreen.

OK

Test Nr.

Ref. Nr.


Attachment

Test 1

1.1 Set the elderly person to a dangerous situation and check if medical staff can confirm the alarm by pressing a confirm button on the touchscreen.

The alarmed medical staff can confirm the alarm by pressing a confirm button on the touchscreen.

OK

Remarks

There is a pop up window when an alarm is receiving with an “Accept”- and a “Reject” –Button. The priority of this requirements has changed from priority3 to priority 1 during the master thesis because this shows the bidirectional communication of a service.

5.4 Change situation


(OK/NOK) Comment

SWRS- CSM -01


Verify that the MAMS allows medical staff to change their activity status to Making bed, With elderly person, resting and away.

OK

Test Nr.

Ref. Nr.


Attachment

Test 1

1.1 Set the activity status of medical staff to the different state and check it.

The medical staff can change their activity status to Making bed, With elderly person, resting and away.

OK



Page 32 of 36

Test Nr.

Ref. Nr.


Attachment

Remarks


(OK/NOK) Comment

SWRS- CSM -02


Verify that the MAMS allows to change status according to the medical staff appointments in the mobile device’s calendar.

NOK

Test Nr.

Ref. Nr.


Attachment

Test 1

1.1 Put different appointments in the mobile device’s calendar and check if the activity status of medical staff changes according them.

The activity status changed according the appointments in the mobile device’s calendar of the medical.

NOK

Remarks


5.5 Check location


(OK/NOK) Comment

SWRS- CHL -01


Verify that the MAMS is able to receive the Bluetooth IDs of “location indicators”

OK

Test Nr.

Ref. Nr.


Attachment



Page 33 of 36

Test Nr.

Ref. Nr.


Attachment

Test 1

1.1 Check if the MAEP receives the Bluetooth IDs of “location indicators”

The MAEP receives the Bluetooth IDs of “location indicators”

OK

Remarks


(OK/NOK) Comment

SWRS- CHL -02


Verify that the MAMS is able to measure the RSSI of the Bluetooth “location indicators”.

OK

Test Nr.

Ref. Nr.


Attachment

Test 1

1.1 Check if the MAEP measure the RSSI of the Bluetooth “location indicators”.

The MAEP measure the RSSI of the Bluetooth “location indicators”.

OK

Remarks


(OK/NOK) Comment

SWRS- CHL -03


Verify that the MAMS chooses the” location indicator” with the strongest RSSI with its ID saved in the SBA database.

OK

Test Nr.

Ref. Nr.


Attachment



Page 34 of 36

Test Nr.

Ref. Nr.


Attachment

Test 1

1.1 Go to a room with different Bluetooth “location indicators” and check if the MAEP chooses the” location indicator” with the strongest RSSI with its ID saved in the SBA database.

The MAEP has chosen the” location indicator” with the strongest RSSI with its ID and saved in the SBA database.

OK

Remarks

Concept change; all location indicators have a Bluetooth id beginning with EMS_<room_name> so the mobile application decides itself if the received Bluetooth id is a “location indicator” of the EMS





(OK/NOK) Comment

SWRS-USA-01


Verify that the MAMS starts up automatically when the mobile device starts up.

NOK

Test Nr.

Ref. Nr.


Attachment

Test 1

1.1 Switch off the mobile device. Switch on the mobile device and check if the MAMS start up automatically.

After switching on the mobile device the MAMS started up automatically

NOK

Remarks

The application must be started up manually. This feature has priority 2 (wish point) so due to the time it is not implemented.



Page 35 of 36

6 Documentation


(OK/NOK) Comment

SWRS-DOC-01

6 documentation Verify that a Design Description is written for this project with all applications described using UML and clear diagrams.

OK

Test Nr.

Ref. Nr.


Attachment

Test 1

1.1 Check if Design Description is existing for this project. Document existing OK

1.2 Check if all applications are described using UML and clear diagrams

UML and clear diagrams existing and matching to application

OK

Remarks


(OK/NOK) Comment

SWRS-DOC-02

6 documentation Verify that an evaluation of the uMove API is written containing the following points:

- Usability of uMove (programming point of view) - Problems and bugs encountered

Proposition of improvement.

OK

Test Nr.

Ref. Nr.


Attachment

Test 1

1.1 Check if description existing about Usability of uMove (programming point of view).

Chapter existing OK



Page 36 of 36

Test Nr.

Ref. Nr.


Attachment

1.2 Check if description existing about uMove Problems and bugs encountered

Chapter existing OK

1.3 Check if description existing about uMove Proposition of improvement

Chapter existing OK

Remarks

7 Test result summary

According to the test results, the tests have been:

PASSED NOT PASSED I let this application pass this test because no priority 1 points containing the uMove framework is missing. A very few priority 1 points containing the GUI are missing but the decision was to focus on the uMove parts. During the master thesis we discussed to change priority of the alarm accepting because this shows the bidirectional communication of a service. This part of uMove was finished as recently as this master thesis was running.

Release of test results and measures Role Name Function Date / Signature

Author: René Süssmilch Tester 06.09.2010 Initials:

8 Document history

Version Date Creator Description of modification

1.0 19.08.2010 René Süssmilch Newly created

Project Summary Version 1.0

T-213-20 / V 1 EMS_Project_Summary-v1.0.doc

Page 1 of 4

Process:

Project Summary


Number MT-10-01.14

Version: 1.0


Template: T-213-20 Project Summary




Postfach 325, CH-3000 Bern 22, [email protected], +41 31 84 83 272 Keywords uMove, elderly person, monitoring, KUI, kinetic user interface

Release





Page 2 of 4

1 Introduction

Within this proof of concept study I realized a functional elderly monitoring system including the server based application and the two different mobile applications for the elderly persons and the medical staff. The applications were planned and realized as fast prototypes. This project was the first one which used the uMove framework of the PAI Group of the University of Fribourg in its complete functionality. It required more reworks of the EMS software and time due to the reason that some parts of the framework were still under development and the documentation not daily updated. This means that not all of the requirements specified in the SWRS[Ref1] are implemented. The SWRS shows instead the requirements of a possible end product. Together with the advisor and expert I had to set certain priorities. Anyhow, studying the framework code and the helping hand of the adviser Pascal Bruegger helped to understand the functionality and usage of the uMove framework. During this project working with this framework, I got the estimation that the uMove framework is a really powerful and serviceable utility to implement such a kinetic user interface application.

2 Reached goals

As described in [Ref2] a fast prototype implementing the main functions of an elderly monitoring system was specified and implemented during this master thesis.

Reached Goals server based application:

• Elderly persons can be set up and modified in the application

• Persons of trust can be allocated to elderly persons

• Safe locations can be allocated to elderly persons

• Elderly person’s location can be found in the GUI (visual on the floor plan and in the tree view)

• Two floors are implemented in this application

• On clicking on the elderly person in the tree view its information e.g. location, activity is shown in the GUI

• The SBA receives location and context data from mobile device and process them.

• The SBA appraises situations using the received data

• The nearest available person of trust is alarmed when an elderly person is in a dangerous situation

• All available persons of trust on the same floor were alarmed when an elderly person is in a critical situation

• The SBA shows in the GUI which member of the medical staff accepted the alarm

Reached goals mobile application for elderly person

• The temperature of the environment of the elderly person is checked

• The MAEP reads out the values of the 3 axes of accelerometer and decide the activity of the elder person (normal behavior, strange behavior, falling)

• A location tracking is implemented using the RSSI of Bluetooth.

• All context and activity changes are sent to the SBA



Page 3 of 4

Reached goals mobile application for medical staff

• The member of the medical staff can change its activity via a dropdown list

• Medical staff is alarmed by earcon when an elderly person for which he is responsible is in dangerous situation

• Medical staff is alarmed by a continuous earcon when an elderly person for which he is responsible is in critical situation

• Medical staff is able to confirm an alarm

• A location tracking is implemented using the RSSI of Bluetooth.

• All context and activity changes are sent to the SBA

3 Future work

This proof of concept shows that uMove is absolutely suitable for implementing such an elderly monitoring system. If this concept of elderly monitoring system will be pursued further to a market-ready product the ideas and also the analyses and design can be used further but the implementation should start again from scratch, because this implementation really is just a fast prototype. To make this project successful there must also be some discussions with stakeholders to see what the hospitals, nursing and rest homes really need. It is important to know that this implementation is just a proof of concept and shouldn’t be used to go further. There are also some open questions:

• Location tracking: The location tracking must be switched to a method which is much more energy efficient.

• Fall detection: the fall detection must be enhanced with a more accurate algorithm

• Root Rights on Android mobile: at the moment root rights are used for installing the uMove framework on the Android phone. It is not possible for all Android phones to get root rights.

• Easy to use hardware: A mobile phone like the Motorola Milestone is not handy for an elderly person � an easy to use hardware without touch screen etc has to be developed



Page 4 of 4

4 Using uMove

Pervasive computing was absolutely unknown to me, so I needed to be introduced to this topic first. After the general introduction of this theme we started with the introduction of the uMove framework including a demo application called Robin. Based on Robin I started to implement the elderly monitoring system according to the SWRS. With the introduction of Pascal Bruegger the setup of the e-space, the illustration of the surrounding area, was ready to implement. I noticed that the uMove is much more flexible than the implemented GUI could be. Adapting a new floor in uMove could be done in 10 minutes after understanding how to do that. But adapting the GUI needs much more time. Due to the study of the framework code and the helping hand of the advisor Pascal Bruegger, I could arrange a prototype of an elderly monitoring system including the server based application and the two different mobile applications for the elderly person and the medical staff. The connection between server and mobile application works well and needs not many settings from the programmer. But it is to say, that working with this version of uMove I got, was not the easiest thing because the basic concept of uMove, that almost the whole application is located in framework classes, was first a bit unusual for me and needed some time to understand. Also upgrading and adjustments during this master thesis delayed the work. In fact of its power and also that the framework was not fully finished and tested, I had to invest a lot of time for knowing how to implement the sensor sengets, entity tracker, service etc. But as conclusion I can say, after working more than 300 hours with the uMove framework, that the concept and implementation is really adapted for a project like the elderly monitoring system. The longer I worked with the uMove framework, the more I got the estimation that the uMove framework is a really powerful and serviceable utility which is on a good way. But it needs also some work to be really usable for larger and really used projects.

5 uMove Problems and bugs

During the implementation of this elderly monitoring system some smaller bugs were found. I reported these findings directly to my advisor who adapted the framework. So there is just one major bug known, which is not corrected until yet:

• From time to time the framework returns empty elements. Because of this known bug I had to implement almost everywhere a null-check for the received elements.

Also an open issue for the uMove crew is to generate a useful documentation. I hope I could give my advisor a good hint for the documentation with my questions during this project.

6 References

Ref 1 René Süssmilch, Software Requirements specification_v1.0.doc Ref 2 René Süssmilch, EMS_Software_Test_Protocol_v1.0.doc

documentation overviewstatic.sws.bfh.ch/download/mt-10-01-14-doc.pdf · documentation overview...

Documents