Robotic Assistance for Orientation Disease

SAFETY, EVALUATION AND ACCEPTABILITY ASPECTS IN REHABILITATION AND ASSISTIVE TECHNOLOGIES
FINAL PROJECT
PARIS, FRANCE, DECEMBER 21ST, 2017
Robotic Assistance for Orientation
Disease
LUÍS RITA1

1
3702256, luis.domingues_rita@etu.upmc.fr

Alzheimer’s Incidence HAZOP-UML Zenbo Wearables

ROBOTIC ASSISTANCE FOR ORIENTATION DISEASE
2
Introduction
A. Alzheimer’s Disease
It’s a chronic neurodegenerative disease that is believed to be the responsible for 60 to 70% of
all cases of dementia in the world. It was described (1906) and later named Alzheimer’s disease
as a tribute to Alois Alzheimer, who was a German psychiatrist and pathologist.
At an early stage, the symptoms are often mistakenly attributed to ageing. This happens
once the evolution may be very slow and, in most of the cases, appear after 65 years old (4% to
5% arose earlier).
Several hypotheses were already formulated in an attempt to understand what are the
causes behind Alzheimer’s disease:
® Genetic;
® Cholinergic;
® Amyloid;
® Tau;
® Other hypothesis.
Multiple epidemiological studies were
already undertaken, trying to find modifiable factors
that could lead to a decrease in the incidence of the disease. In spite of not exist a strong
correlation, hypocholesteremia, hypertension, diabetes and smoking are known to increase the
onset of the disease, as well as worsen the symptoms of it.
A lot of research around this topic is being performed across the globe, trying to find new
ways of earlier diagnosis and therapies to postpone or cure the disease. Recently, Bill & Melinda
Gates Foundation made an investment of 100 million dollars in Alzheimer’s research. In fact, they
pretend to develop new treatment approaches, since the recent trials have not been achieving
satisfying results.

Figure 1 – Prevalence of Alzheimer’s disease worldwide.

3
B. Unified Modelling Language (UML)
UML is a graphical notion that can be very useful in the development of many projects since an
early stage. It is considered a language (not a method) and a complete specification can be found
online Object Management Group UML webpage [1]. The current version provides 13 different
types of diagrams, whereas some are static and other dynamics. Inside the last category, the ones
widely used are:
® Use case – often used at the beginning of any project development;
® Sequence – also used in an initial phase, but it adds a relative time lapse to the planning;
® State machine – commonly used in reactive systems, such as robot controllers.

C. Use Case Diagrams
Use Case Diagrams present the system being studied, the actors, the communication between
them and the objectives of its use: use cases. Moreover, the simplicity of these diagrams
significantly enhances the communication among the developers, analysts and users responsible
for the system. These graphical representations are commonly completed with a textual
reference to pre, post conditions and invariants present.
Important to highlight that some representations should be avoided, always considering
the simplicity and clearness of the system. In fact, sometimes when analyzing robots, their
mechanical part is separated of the controller (including hardware and software). Being the 1st

one considered as an actor and the second as the box that includes the use cases. Plus, sometimes
relations between use cases are represented when preparing these diagrams. Both situations
must be avoided once they can lead to misunderstandings and to an unclear application of the
HAZOP-UML method.

D. Sequence Diagrams
It’s a type of sequence diagram which pretends to depict, graphically, the interaction between
objects. In fact, the messages exchanged among them are displayed in a chronological order so
that it allows the specification of simple runtime scenarios or to simulate real world interactions
like in the project.
Each object is depicted using vertical lines, commonly called: lifelines. And the exchanged
messages are horizontal. Moreover, a general timescale can be defined from the top to the
bottom of the diagram.

4
E. State Machines
A state machine is a mathematical model which consists in a finite set of states and transitions
that will occur accordingly to some external inputs. It’s an abstract concept which is limited to
one state at any given time. Thus, it is defined by a list of its states, initial state and conditions for
each transition. Commonly represented by nodes and lines are the states and transitions,
respectively. More specifically, between the start state and destination state is a line that can
have the following facultative form: event [guard]/action ():
Event – is the trigger for a transition to take place. It can be a signal event, call event, change
event or a temporal event;
Guard – condition to be met by the event;
Action – list of actions performed immediately after the transition.
Some examples are the vending machines, which dispense of products will be affected
by the sequence of actions performed by the user; elevators, whose sequence of stops will vary
upon the chosen floors by the riders… Or, in the case given below, it is a simplified version of
MIRAS state machine.

F. Risk Analysis Techniques
There are 4 techniques that are widely used in risk analysis: Preliminary Hazard Analysis (PHA),
Hazard Operability Analysis (HAZOP), Fault Tree Analysis (FTA), and Failure Mode, Effects, and
Criticality Analysis (FMECA).
Figure 2 - MIRAS Figure 3 – MIRAS state machine.

5
Once some of them are more likely to be applied in an initial development stage (PHA
and HAZOP), others are more dedicated to reliability issues in more advanced stages (FTA and
FMECA).

G. HAZOP
HAZard OPerability collaboration technique is intended to identify the main deviations of
parameters in a given process. Systematically, this is done with the conjunction of:
® System parameters: temperature, battery (…);
® Guide words: related to the nature of the deviation (no, more, less…)
After the identification of each deviation, the goal is to assess the possible causes,
consequences, safeguards, actions required, comments… All of them are then gathered in a table
like the one below (Table 1).
Even though HAZOP has proven to be efficient, the results may be questionable when the
number of parameters and deviations is very high. Hence, this method can lead to a big allocation
of human resources and can be a time-consuming process. Due to this combinatorial explosion,
it is important to assure a good communication among the analyst and the team members to
limit the analysis to the more relevant topics.
H. HAZOP-UML
Based on the UML description of the system, it is intended to consider some of the elements
present and analyze the deviations those parameters can suffer.
It is well worth it to remind that there is no hazard identification technique able to identify
all the hazards. Plus, we are focusing in the operational issues linked to the human-robot
interaction.
Table 1 – Example of application of HAZOP.

6
Thus, the general procedure should follow the next method: for each entity, attribute
and guideword, one should identify one or more deviations and analyze it/them. As said before,
the cause, consequences, preventive actions (…) should be considered. To perform such study,
the columns of Table 1 should be filled with the following criteria:
1. Entity: UML element in each study that is being applied;
2. Line number: for traceability;
3. Attribute: Considered attribute (e.g., a pre/post condition or message);
4. Guide word: applied guideword (Table 2);
5. Deviation: based on the entity, attribute and guideword;
6. Use Case Effect: effect at the use case level;
7. Real World Effect: effect in the real world;
8. Severity: classifying the effect, in a worst-case scenario;
9. Possible Causes: suspected causes of deviation (e.g., hardware, software, user);
10. Safety Recommendations: in order to prevent or protect;
11. Remarks: analysis explanations and extra recommendations;
12. Hazard Numbers: real world effects are identified with numbers to the users easily
navigate between results of the study and the HAZOP-UML tables.
Finally, one expects to obtain from a completed study:
® Compilation of all the identified hazards;
® A list of hypothesis to perform the analysis, that should be previously confirmed by
domain experts;
® Safety recommendations relative to the hazards.

Figure 4 – HAZOP-UML process.
Figure 5 – Performing HAZOP-UML method.

FINAL PROJECT
Table 2 – Guide words list and generic interpretation for sequence diagrams messages.

FINAL PROJECT
Question 1

The modeled scenario concerns an old man with orientation problems caused by a moderate
Alzheimer’s disease.
While walking outside, due to patient’s health condition, he starts to get lost on the
streets. Whenever this occurs, he ends up being found by a passer-by, who call the police. After
that, when the police meet the patient, two different scenarios can occur accordingly to the
information given in the text:
1st
Possibility
The police immediately bring the patient back home (as written in the question 1o
/, and
as represented by (1) in Fig. 6);
2nd
Possibility
The police take the patient to the police station, where they call the patient’s daughter,
who brings him back home (as written in the text given in the statement, and as represented by
(2) in Fig. 6).
The interactions between
the different actors will be
modeled using a UML sequence
diagram. Therefore, it is necessary
to start by defining the objects
involved in the different scenarios
that we intend to study: Patient,
Passer-By, Police and Daughter.
After defining those, an
UML sequence diagram is now
ready to be designed. An online
tool called draw.io was used
(available in the following link:
https://www.draw.io/). The
resultant diagram is shown in Fig.
6.

Figure 6 – Sequence Diagram.

9
Question 2
A. Wearable Location Tracking Device

Now, we are going to consider two different devices intended to help the patient while wandering
on the streets.
“The first one is a wearable location tracking device (based on GPS), connected to a
caregiver, that can detect when the patient is wandering, and activate an audio discussion with
the patient. The caregiver can then contact a trained team to intervene.”
As it was done in the previous question, it is necessary to start by defining the main
objects involved in the basic scenario, which corresponds to the
patient getting lost on the streets.
Having the needed objects well defined, the UML sequence
diagram was then modelled, and the resulting diagram is
represented in Fig. 8.
In this case, it was considered that once the trained team
is contacted to intervene, it is responsible for meeting with the
patient and after that bringing him back home (as represented by (1) in Figure 8). In addition,
another possibility was also considered. In the case of not being required the intervention of a
trained team (if the quality of the call is good enough, and if the patient has a good mental status,
for instance), the patient may be able to come back home only with the help of the caregiver,
which is given through the audio discussion that is established (represented by (2) in Fig. 8).
Figure 7 – Wearable location tracking device.

10

Figure 8 – Sequence diagram – wearable location tracking device.

11
B. Companion Robot
The second scenario is described as follows:
“the use of a companion robot that can also provide a location tracking of the
patient following him outside. It can establish an audio and video communication
with a caregiver. The robot has also autonomous functions to engage
communication directly with the patient when it detects any issue. It can also
answer to basic requests like “where is my home”, and guide the patient to his
home.”
In Companion Robot’s case, it is assumed the robot presents pretty
developed autonomous capabilities, thus the caregiver responsible by the patient,
just has to follow up the events, eventually by video chatting with him. The UML
Sequence diagram is presented in the next page (Fig. 10).

Figure 9 – Zenbo robot.

12
Figure 10 – UML sequence diagram of Zenbo.

13
Question 3
Severity Scale
Based on the case under study, the following table (Table 3) was developed in order to be able to
address to each hazard a severity level. The PHA (Preliminary Hazard Analysis) can be found in
Table 4.
Rank Severity
1 Minor
2 Moderate
3 Serious
4 Severe
5 Critical
6 Maximal
Table 3 – Severity Scale
Probability Scale
To be able to build up a Risk Matrix (Table 5), the likelihood of each hazard had to be added to
analysis (Table 4).
Likelihood Frequency (per year)
Frequent ≥ 10
Probable 1
Occasional 10-2

Rare 10-4

Almost Impossible 10-6

Table 4 – Probability Table.

14
Risk Matrix
By combining the probabilities of each event with its severity, we obtain a risk matrix. It cannot
be considered an objective construction, once its values are strongly influenced by the given
context and the current values of a society.

Preliminary Hazard Analysis
In the next pages, PHA tables will be present regarding the 2 cases.
® Wearable Location Tracking Device (Table 6)
In this case, it was assumed the device was a watch permanently used in the wrist, to prevent the
patient to forget it at home. Plus, it has a 2-way audio communication capability, a GPS receptor
inside and no possibility for video interaction. Related to the caregiver, every time there is an
alert he is notified. It is supposed to available 24/7, even though, in very sporadic situations, he
may not be available.
® Companion Robot Zenbo (Table 7)
Again, some assumptions had to be made regarding the functioning and proper use of this device.
Firstly, it was assumed that the companion robot has a similar appearance to Zenbo (presented
Probability
Severity
Frequent [5] Probable [4] Occasional [3] Rare [2]
Almost
Impossible [1]
Minor [1] I L N N N
Moderate [2] H I L N N
Serious [3] H H I L N
Severe [4] H H H I L
Critical [5] H H H H I
Maximal [6] H H H H I
Table 5 – Risk matrix.

15
in Fig. 9 of the statement), and that it is prepared to walk outside, on every type of floors and also
under any weather condition. Secondly, it was assumed the device is turned on and off by the
patient, before leaving and after arriving home. Then, it was assumed that the location tracking
system of this device is also based on a GPS system (just like in the wearable device). It was also
assumed that as soon as wandering or any other abnormal condition is detected, the audio and
video communication is established with the caregiver. Regarding the functioning of this, it was
considered that the sound and the video systems would operate independently of each other on
the robot, which means that, if one of them fails, the other one can still work (for instance, the
patient can see the caregiver on the screen, but he cannot listen to him, in the case of failure of
the sound system, only). As soon as wandering or any other abnormal condition is detected, the
autonomous functions of the robot can also be activated, and automatically a direct
communication is established between the patient and the robot. In order to perform this
communication, it was assumed that now only the sound system is required. Another important
assumption was made regarding these too methods of communication, which concerns the
priority of their establishment. Thus, it was considered that the communication that is first
activated is the audio/video with the caregiver. Only in case of its failure, the direct
communication with the robot is activated. Finally, regarding the capacity of answering to basic
requests, it was assumed that, in order to do this, the robot possesses, not only a sound system
(that allow it to answer the request out loud), but also a recording systems (that listen and records
the request asked by the patient). It was also considered that the robot is able to answer to simple
questions regarding the position of the patient and his way back home, as well as other simple
questions of the daily life (such as “what time is it?”). A trained team can still be contacted by the
caregivers, if necessary.

FINAL PROJECT
Reference Hazard
Accidental Event
(what, where &
when)
Probable
Causes
Contingencies/Preventive
Actions
Probability Severity Level
1 Mechanical Hazards
1.1 Damaged screen
display
Patient unable to
use/interact with
wearable while
walking outside
- Heavy
shock/collision;
- Poor durability of
the materials;
- Sturdier materials;
- Use of accessories (temperate glass)
to increase protection of the screen.
4 2 I
1.2 Untighten wearable
bracelet
Patient may lose his
location wearable
while walking outside
the materials;
- Misuse of the
wearable;
- Production of bracelets with
different sizes;
- Production of adjustable bracelets
accordingly to the wrist of the
patient.
3 2 L
1.3 Compromised GPS
receptor
Patient gets lost
- Misuse of the
wearable;
- Poor quality of the
receptor.
- Lack of shock absorption
mechanisms to prevent violent
impacts;
2 5 H
1.4 Dysfunctional
microphone/speakers
Patient unable to
communicate with
caregiver while
walking outside
- Misuse of the
wearable;
the materials;
- Include in the device a good
isolating mechanism such it prevents
the entrance of water through them.
2 5 H
2 Electrical Hazards

17
2.1 Battery discharge
Patient unable to use
the wearable and its
functionalities while
walking outside
- Short Circuit;
- Aged device.
- Periodically substitution of the
battery;
- Adjust device settings (e.g. -
brightness) to save energy.
5 5 H
2.2 Electric shock
Patient gets shocked
in a running day
- Loss of some of the
waterproof
properties;
- Aged device.
- Avoid handling device with wet
hands;
- Design it such that it can resist wet
weather.
2 1 N
2.3 Battery dysfunction
the wearable and its
walking outside
- Aged device.
battery;
- Avoid overheating of the device.
1 5 I
3 Human Hazards
3.1 Absent caregiver
No one to help him in
case of need while
walking outside.
- Requested in an
unusual time (e.g. –
during the night).
- Implement notification system in
the caregiver’s phone or smartwatch. 2 5 H
3.2 Patient hurts himself
Patient gets injured
while using the
device outside
- Presence of cutting
edges in the device.
- Use tough materials to avoid their
breakage;
- Use a cover around the wearable if
it is inevitable the presence of certain
edges.
1 2 N
4 Software Hazards

18

4.1
Inaccurate GPS
localization
Patient gets lost
while walking outside - Weak GPS signal. - Alarm should aware the user for a
low GPS signal. 4 4 H
4.2 Frozen OS
the device and its
locating
walking outside
- Lack of updates by
OS developer;
- Aged device.
- Keep up-to-date versions of
software (apps and OS).
2 5 H
4.3 Hacking
Loss of privacy of the
patient while walking
outside
- Improper data
protection.
- Follow security guidelines regarding
anti-virus usage;
- Use of secure means of
communication between user and
caregiver.
1 2 N
Table 6 – PHA wearable location tracking device.

FINAL PROJECT
Reference Severity Description
1.1 I
Although the patient may be completely
prevented by interacting with the robot,
it may still communicate and ask
questions to the machine or caregiver.
1.2 L
Due to an unexpected range of
movements, the robot may suddenly
cause the patient to fall, to collide with
him or with the environment, damaging
itself.
1.3 H
Due to a collision or overheating, for
instance, the GPS receptor in the robot
may get affected and lead the patient
through unexpected ways.
1.4 H
If the main sensors the robot use get
damage, it will turn it useless. Not being
capable of establishing the
communication between the caregiver or
taking the patient home.
2.1 H
The energy consumption of the robot
may widely vary according to
environment features. Such as
temperature, ground inclination… This
may cause big battery variations and lead
to unexpected discharge of it.
2.2 N
In the case of the robot, this is not so
hazardous as before, once the contact
with the user doesn’t happen so often.
2.3 I
An aged device and an unsuitable
sequence of charging cycles at home may
lead to decreased capabilities of the
battery.
3.1 H
It is not such a big issue in this case, once
the robot itself possess a enhanced
autonomous behaviour when comparing
to the wearable.
3.2 N
Once both patient and robot do not
interact so often, the probability of
getting itself hurt while using the device
is decreased.
4.1 H
The weather may strongly influence the
signal reception. Thus, based in forecasts
and GPS receptor quality, the user may
be advised not to use the robot.
4.2 H
An issue like this, may completely
inactivate a robot. Thus, every
functionality will cease and prevent the
user to communicate with anyone else.
Added to this is the problem the robot

20
itself is heavy and the patient may be
unable to carry it with him.
4.3 N
A problem that arises in any device that
is network connected and which registers
user activity is the lack of privacy.
Although this may not directly be
considered a threaten to the user, in a
long term may increase the probability of
thief activity.
Table 7 - Explanation of the chosen severity estimations of the hazards presented.

FINAL PROJECT

22
Reference Hazard
Accidental
Event (what,
where & when)
Probable
Causes
Contingencies/Preventive
Actions
Probability Severity Level
1 Mechanical Hazards
1.1 Damaged screen display
Patient unable to
use/interact with
wearable while
walking outside
- Heavy
shock/collision;
the materials;
- Sturdier materials;
- Use of accessories (tempered glass)
to increase protection of the screen.
4 2 I
1.2 Uncontrolled motion
Patient may fall or
damage the device
while waking
outside
- Issues with the
robot actuators;
- Controlling
problems;
- Not adapted to
the environment.
- Regular maintenance required;
- Multiples sensors that overcome
local problems.

2 5 H
1.3 Compromised GPS receptor
Patient gets lost
while walking
outside
- Misuse of the
wearable;
- Poor quality of
the receptor.
- Lack of shock absorption
mechanisms to prevent violent
impacts;
2 5 H
1.4 Dysfunctional
microphone/speakers/camera
Patient unable to
communicate with
caregiver while
walking outside
- Misuse of the
wearable;
the materials;
- Include in the device a good
isolating mechanism such it prevents
the entrance of water through them.
2 5 H
2 Electrical Hazards

23
2.1 Battery discharge
Robot shuts down
during the walk.
- Short Circuit;
- Aged device.
battery;
- Adjust device settings (e.g. -
brightness) to save energy.
5 5 H
2.2 Electric shock
Patient gets
shocked when
touching the robot
in a rainy day (while
walking outside)
- Loss of some of
the waterproof
properties;
- Aged device.
- Avoid handling device with wet
hands;
- Design it such that it can resist wet
weather.
1 1 N
2.3 Battery dysfunction
Robot suddenly
shuts down while
walking outside.
- Aged device.
battery;
- Avoid overheating of the device.
1 5 I
3 Human Hazards
3.1 Absent caregiver
No one to help him
in case of need
while walking
outside.
- Requested in an
unusual time (e.g. –
during the night).
- Implement notification system in
the caregiver’s phone or
smartwatch.
2 5 H
3.2 Patient hurts himself
Patient gets injured
while using the
device outside
- Presence of
cutting edges in the
device.
- Use tough materials to avoid their
breakage;
- Use a cover around the wearable if
it is inevitable the presence of
certain edges.
1 1 N
4 Software Hazards

24
4.1 Inaccurate GPS localization
Patient gets lost
while walking
outside - Weak GPS signal. - Alarm should aware the user for a
low GPS signal. 4 4 H
4.2 Frozen OS
Patient unable to
use the device and
its locating
walking outside
- Lack of updates
by OS developer;
- Aged device.
- Keep up-to-date versions of
software (apps and OS).
2 5 H
4.3 Hacking
Loss of privacy of
the patient while
walking outside
- Improper data
protection.
- Follow security guidelines
regarding anti-virus usage;
- Use of secure means of
communication between user and
caregiver.
1 2 N
Table 8 – PHA Zenbo.

FINAL PROJECT
Reference Level Description
1.1 I
Although the patient may be completely
prevented by interacting with the robot,
it may still communicate and ask
questions to the machine or caregiver.
1.2 H
Due to an unexpected range of
movements, the robot may suddenly
cause the patient to fall, to collide with
him or with the environment, damaging
itself.
1.3 H
Due to a collision or overheating, for
instance, the GPS receptor in the robot
may get affected and lead the patient
through unexpected ways.
1.4 H
If the main sensors the robot use get
damage, it will turn it useless. Not being
capable of establishing the
communication between the caregiver
or taking the patient home.
2.1 H
The energy consumption of the robot
may widely vary according to
environment features. Such as
temperature, ground inclination… This
may cause big battery variations and
lead to unexpected discharge of it.
2.2 N
In the case of the robot, this is not so
hazardous as before, once the contact
with the user doesn’t happen so often.
2.3 I
An aged device and an unsuitable
sequence of charging cycles at home
may lead to decreased capabilities of the
battery.
3.1 H
It is not such a big issue in this case,
once the robot itself possess a enhanced
autonomous behaviour when comparing
to the wearable.
3.2 N
Once both patient and robot do not
interact so often, the probability of
getting itself hurt while using the device
is decreased.
4.1 H
The weather may strongly influence the
signal reception. Thus, based in
forecasts and GPS receptor quality, the
user may be advised not to use the
robot.
4.2 H
An issue like this, may completely
inactivate a robot. Thus, every
functionality will cease and prevent the
user to communicate with anyone else.
Added to this is the problem the robot

26
itself is heavy and the patient may be
unable to carry it with him.
4.3 N
A problem that arises in any device that
is network connected and which
registers user activity is the lack of
privacy. Although this may not directly
be considered a threaten to the user, in
a long term may increase the probability
of thief activity.
Table 9 - Explanation of the chosen severity estimations of the hazards presented.

27
Question 4
First, it was necessary to identify all the attributes for the study, taking into account the objects
that constitute the UML sequence diagram. We should keep in mind the objects identified in the
question 2o/ and the attributes (messages), to model the second scenario of the companion
robot.
Finally, we are now ready to perform the HAZOP-UML analysis based on the UML
Sequence Diagram proposed for the companion robot, and presented in the Fig. 10. The resulting
table is presented below, in Table 11. It is still important to notice that, for some attributes, not
all guidewords (Table 10) were used, since they were considered as not applicable to the
corresponding case study.

Table 10 – Guidewords regarding General Ordering.

FINAL PROJECT
Attribute Guideword Deviation
Use Case
Effect
Real
World
Effect
Severity
Possible
Causes
Safety
Recommendations
Remarks
Hazard
Number
wanderingDetection()
No Wandering is
not detected
GPS, magnet,
gyroscope not
working
Patient
does not
receive
help
Serious
- Robot
collision with
environment;
- Short circuit
caused by
wet
surroundings.
- Often perform
software and hardware
checks;
- Addition of a reset
button;
Help is only
activated
when is
wandering
as well. No
help from
the robot
itself or
caregiver.
HN1
Other than
Wandering is
mistakenly
detected
GPS, magnet,
gyroscope not
working
properly
Patient
receive
help when
does not
need
Moderate
- Hardware/
software
issues.
- Often perform
checks;
button;
Patient may
receive help
when he
needs and
when he
does not.
HN2
locationRequest() No
Tracking
system does
not work
GPS not
working
Patient
gets lost Serious
- Failure
when
synchronizing
the whole
global
positioning
system;
- Failure of
the GPS
- Use an atomic clock to
avoid discrepancies
between GPS receiver
on-board clock and the
GPS time. Thus,
avoiding discrepancies;
- Robot alert when
there is low signal.
In this case,
it becomes
more
difficult for
the
caregivers
to help the
patient,
since they
HN3

29
receivers
when
analyzing the
three signals
from
satellites in
the system
(when doing
the
trilateration
calculation to
pinpoint the
exact
location of
the receiver).

do not
receive any
information
about the
position of
the patient.

Other than
Tracking
system outputs
wrong
positions of the
patient
GPS not
working
correctly
Patient
gets lost Moderate HN3 HN3
Once
caregivers
receive the
wrong
position of
the patient,
they will not
be able to
guide him.
HN4
More than
More than one
position of the
patient is
detected
GPS not
working
correctly
Patient
gets lost Moderate HN3
HN3;
- Robot alert when
there is more than one
position detected
By receiving
more than
one
position,
caregivers
will not be
HN5

30
able to
know
exactly what
is the right
location.
Less than
Detected
positions less
frequently than
expected
GPS not
working
correctly
Patient
As less the
patient
moves, as
better will
be his
location.

HN6
After
Delay detecting
the actual
position of the
patient
GPS not
working
correctly
Patient
Only
possible for
the
caregivers
to detect
previous
location.
HN7
Part of
Lack of
information
regarding the
position of the
patient
GPS not
working
correctly
Patient
In order GPS
to be able to
accurately
locate the
patient it
needs to
have access
to several
coordinates.
HN8

31
Otherwise,
it cannot
help the
user.
answerBasicQuestions()
No
Robot does not
answer to basic
questions
Robot does not
speak/ answer
to the patient
Patient can
get lost
once he
does not
receive
orientation
aid
Serious
- Problems in
the sound
system that
prevents
speakers to
reproduce
any sound;
- Issues with
the
microphone
does not
record
patient’s
request;
- Low
battery;
- Failure of
location
tracking
device.
- Often perform
checks;
button;
- Backup battery to be
activated as soon as
the other fails;
- Promptly initiate
communication with
caregiver;
- Add an alternative
way to show the
answered questions to
the patient (written in a
screen).
Patient can
still be
helped by
the
caregivers.
HN9
Other than
Robot does not
answer to the
patient in the
right way
Wrong answers
provided to the
patient
Patient can
get lost
once he
does not
receive the
Moderate
- Failure of
location
tracking
device;
- Failure of
the control
- Often perform
checks;
button;
The wrong
information
provided by
the robot
may lead to
the loss of
HN10

32
right
information
system
(software
and
hardware);
the patient.
And
contribute
for a
distressing
situation.
Less than
Robot does not
always answer
Robot
sometimes
does not
speak/ answer
to the patient
Patient can
get lost
once he
does not
always
receive
orientation
aid
Moderate
- Failure of
location
tracking
device;
- Failure of
the control
system
(software
and
hardware);
- Often perform
checks;
button;
Patient can
still be
helped by
the
caregivers.
HN11
After
It takes too
long to answer
basic questions
Robot answers/
speaks to the
patient later
than needed
Patient can
get lost if
answers
arrive to
late
Moderate
- Failure of
the control
system
(software
and
hardware);
- Often perform
checks;
Patient can
still be
helped by
the
caregivers.
HN12
Part of
Robot is not
completely
informative
Informations
given are not
enough to help
coming back
home
Patient can
get lost if
answers
are not
enough
Moderate
- Failure of
control
system
(software
and
hardware);

- Often perform
checks;
Patient can
still be
helped by
the
caregivers.
HN13

33
determineShortestWay()
No It does not
return any path
It does not
return any path
Patient can
get lost
because no
path is
provided
Serious
- Problems
with position
location
tracking
device;
- Failure of
control
circuit
(software
and
hardware).
- Send alerts to the
patient as soon as GPS
connexion is lost;
- Perform hardware
and software checks
periodically;
Patient can
still be
helped by
the
caregivers.
HN14
Other than
Sometimes, it
does not return
the shortest
path
It does not
return the right
path
Patient will
take longer
to arrive
home
(longer
way)
Low HN14
- Send alerts to the
patient as soon as GPS
connexion is weak;
- Perform hardware
and software checks
periodically;
In spite of
not
following
the shortest
way, the
patient will
end up
getting
home.
HN15
establishCommunication() No
Communication
between
caregiver and
patient does
not occur
Communication
with caregiver
not well
succeeded
Patient get
lost and
cannot
receive
help from
caregiver
Moderate
- Problems in
the sound
system that
prevents
speakers to
reproduce
any sound;
- Issues with
the
microphone
does not
- Warn patient when
low internet
connectivity;
- Perform hardware
and software checks
periodically;
- Automatically
establish autonomous
communication with
the robot when the one
with caregiver is lost.
If the
patient is
able to ask
short
questions to
the robot,
the
autonomous
mode can
used to take
him home.
HN16

34
record
patient’s
request;
- Patient’s
health state;

More than
Communication
with caregiver
occurs more
than needed
Microphone
and camera are
more often
activated than
needed
Loss of
privacy Low
- Failure of
control
circuit
(software
and
hardware).
- Perform hardware
and software checks
periodically;
In spite of
the
unexpected
situation, it
does not
prevent the
patient to
be helped
by the
caregiver.
HN17
Less than
Lack of
communication
between
caregiver and
patient when
needed
Communication
with caregiver
occurs less
than needed
Patient get
lost and
may not
receive
help from
caregiver
Moderate
- Patient
unable to
understand
information
provided by
the
caregiver;
- Caregiver
not able to
be explicit or
to provide
the right
information.
- Train caregivers.
If the
patient is
able to ask
short
questions to
the robot,
the
autonomous
mode can
be used to
take him
home.
HN18

35

After having the HAZOP-UML we can now extract the list of the identified hazards (presented below in the Table 12), as well as the list of safety
recommendations (presented in the Table 13). All of these tables reference each other using numbered labels for lines, HN in the case of hazards, and Rec in
the case of recommendations. Regarding the list of hazards, its description is obtained by combining both Use Case Effects and Real-World Effects columns of
the Table 12.
After
Time lag
between actual
activation and
communication
Communication
with caregiver
occurs after
needed
Patient get
lost and
may not
receive
help when
needed
Low
- Time lag
caused by
low velocity
internet
connexion.
- Perform hardware
and software checks
periodically;
- Warn patient when
low internet
connectivity.
In spite of
the delay,
the patient
can still be
helped by
the
caregiver.
HN19
Part of
Defective
communication
with caregiver
Communication
not 100%
functional.
Video or audio
missing.
Patient get
lost and
may not
receive
complete
information
Moderate
- Issues with
the
microphone/
camera/
speaker;
- Patient’s
health
condition.
- Perform hardware
and software checks
periodically;
- Train caregivers.
If the
patient is
able to ask
short
questions to
the robot,
the
autonomous
mode can
used to take
him home.
HN20
Table 11 – HAZOP based on UML sequence diagram.

FINAL PROJECT
Hazard Number Hazard Severity
HN1
Wandering is not detected and the
patient cannot be helped by the
robot or caregiver.
Serious
HN2
Sometimes wandering is detected,
others it is not when patient is
outside walking.
Moderate
HN3
Location tracking system is not
working; thus, caregiver cannot
locate the patient and help him.
Serious
HN4
Wrong positions of the patient are
detected. This leads to the
impossibility of helping him.
Moderate
HN5
Multiple positions are output by the
GPS. This hardens the task of locating
the patient by the caregiver or robot.
Moderate
HN6
Locations of the patient are detected
with less frequency. This leads to
some uncertainty regarding the
actual position. Leading to an
increased difficulty of detecting him.
Moderate
HN7
Patient is located only after some
time he is lost. Leading to some
uncertainty regarding his position.
Moderate
HN8
A set of coordinates is needed to
accurately detect the location of the
patient. When this complete info is
missing it may be hard to help him
orientating.
Moderate
HN9
By not answering basic questions, the
autonomous function of the robot is
compromised.
Serious
HN10
Provide wrong information to
patient’s questions may lead him to a
wrong way home.
Moderate
HN11
Robot does not always answer to the
questions. Thus, patient can
occasionally not get help when
needed.
Moderate
HN12
Robot just answers patient request a
while after asking. Although help is
provided.
Moderate
HN13
Robot does not provide complete
answer to the asked question. This
may mistake the patient.
Moderate
HN14
Problems with position location
detection device may lead to the
Serious

37

After extracting the list of hazards from the HAZOP-UML analysis (presented above), it is now
possible to establish a comparison between this and the list of hazards obtained through the PHA
analysis (presented in Table 9). Even though both of the analysis were performed for the exact
same device, it is clear that the resulting lists are totally different.
Starting by simply compare the number of hazards that were possible to identify by using
the two different methods, it is clear that when recurring to the HAZOP-UML analysis, many more
hazards are obtained. In this case it was possible to identify 20 hazards, while in the case of the
PHA analysis, only 12 were obtained.
Another important and clear difference concerns the level of description of the identified
hazards. When comparing the column called Hazard, in the Table 12 with the Description column
of the Table 9, it is evident that in the second case a much more detailed description of the
hazards is obtained. This makes the analysis of the hazards much clearer, which in turn gives rise
to less questions regarding the real meaning of the hazard.
Thus, with all of this being said, it is possible to conclude that the list of hazards obtained
by the HAZOP-UML analysis, provides us much more detailed and precise information, as well as
absence of an advised way to get
home.
HN15
Instead of finding the shortest way,
another one is suggested to the
patient. He will take longer, but get
home.
Low
HN16
No communication established
between the user and the caregiver.
Thus, orientation is only dependent
on the robot autonomous
capabilities.
Moderate
HN17
Communication with caregiver is
established more often than needed. Low
HN18
Communication with caregiver is
established less often than needed.
In these situation, user must only rely
on the autonomous capabilities of
the robot to take him home.
Moderate
HN19
Time lag in the communication
between the caregiver and the
patient.
Low
HN20
Some features of the robot are not
properly working, such as: camera,
microphone or speakers. Hardening
the communication.
Moderate
Table 12 - List of the identified hazards, extracted from the HAZOP-UML analysis presented in the Table 11.

38
much more possible scenarios that may occur. This last advantage of this method, is really
important when thinking that this method is intended to be used at early stages of the system
development. The identification of much more possible hazards can be crucial at this stage and
can be responsible for the need of redesigning the device. The possibility of having lots of hazards
that end up being forgotten or not even being taken into account by the PHA analysis, can have
dangerous consequences on the final safety and performance of the device.

Recommendation Number Safety Recommendations Hazard Number
Rec1 Often perform software and
hardware checks
HN1 HN2 HN9 HN10 HN11 HN12
HN20
Rec2 Addition of a reset button HN1 HN2 HN9 HN10 HN11
Rec3
Use an atomic clock to avoid
discrepancies between GPS receiver
on-board clock and the GPS time.
Thus, avoiding discrepancies
Rec4 Robot alert when there is more than
one position detected HN5
Rec5 Backup battery to be activated as
soon as the other fails HN9
Rec6 Promptly initiate communication
with caregiver HN9
Rec7
Add an alternative way to show the
answered questions to the patient
(written in a screen)
HN9
Rec8
Automatically establish autonomous
communication with the robot when
the one with caregiver is lost.
HN16
Rec9 Train caregivers HN18 HN20
Rec10
Warn patient when low internet
connectivity HN16 HN19
Table 13 - List of Safety Recommendations, extracted from the HAZOP-UML analysis presented in the Table 11.

39
Question 5
First of all, it is important to asses if the Regulation (EU) 2017/745 applies to the Wearable
Location Tracking Device and to the Companion Robot. By checking Article 1, point number 6,
one may realize that any of the criteria from line (a) to (i) is satisfied by the devices under study.
Consequently, we may conclude this regulation applies to both devices.

Showing the definition of medical device present in Regulation (EU) 2017/745, Article 2:

Both devices under study are able to alleviate the impact of Alzheimer’s Disease in the
patients. This happens by providing orientation aid when they are found wandering. Thus, by

40
considering an instrument which main intent is the alleviation or compensation of a disability
(which manifests itself by the loss of orientation), they are considered medical devices under this
definition.
Devices shall be divided in 4 classes (I, IIa, IIb and III), which depend upon the intended
purpose, as well as on the risk. Once both devices are non-invasive and none of the following
rules (from Rule 2 to 4) apply, then they are classified as part of the Class 1.

41
In order to asses when the requirements in Regulation (EU) 2017/745 are
completely fulfilled, one should perform the so called “conformity assessments”.
“Notified body” is the one in charge of calibrating, testing, inspect and certificate are
some of the activities included in the assessment.
Prior to placing or putting into service a device in the market, it is the
responsibility of manufacturers to undertake an assessment of that device following
the conformity procedures set in the Annexes IX to XI.
After drawing up the technical documentation needed (presented in the Annexes II and III
of the Regulation), manufacturers of Class I devices shall issue the conformity of their devices
under the EU declaration of conformity.
Regarding the technical documentation referred above, it shall be presented in a clear
organised and unambiguous manner and usually includes the following elements (Annex II):
® Device description and specification, including variants and accessories;
A general description of the device including its purpose, principles and modes of operation
and an explanation of some of the novelties are some of the features that should be provided.
More technical specifications such as dimensions, performance attributes of the devices, any
variants/configurations and accessories that might appear in the product specification available
to the user (e.g. – brochures or catalogues).
® Information to be supplied by the manufacturer;
For instance, instructions in multi languages (in those accepted in the Member States)
where the device will be sold, should be provided.
® Design and manufacturing information;
In order to understand some of the design stages used in the product. As well as, to locate
and identify all sites where the product is designed and manufactured. This includes suppliers
and sub-contractors.
® General safety and performance requirements;
General safety and performance requirements, methods or methods used to demonstrate
conformity
® Benefit-risk analysis and risk management;
® Product verification and validation;
Focusing now on the notified bodies, there are some important details that shall be
guaranteed in accordance to the Regulation, especially regarding its authorities and requirements
(Chapter VII).
Firstly, the authority responsible for the notified body shall: be established and
Figure 10 – EU declaration of
conformity logo.

42
undertaken in order to safeguard the confidential aspects of the information obtained, and the
objectivity and impartiality of its activities, so that possible conflicts of interest with the
conformity assessment bodies can be avoided; be organized having in mind that the decisions
related to designation and notification cannot be made by the same personnel who carried out
the assessment; not perform the activities on a commercial or competitive basis; and finally, have
always enough competent personnel available for the proper performance of its tasks. (Article
35)
Secondly, they shall satisfy some general, organizational, resource and process
requirements, so that they can then fulfil the tasks for which they are designated in accordance
to the Regulation.
In conclusion, the goal is to produce devices which perform such that it accomplishes the
intended goal without compromising the integrity of the patient or device. At the end, all the risks
should be considered and weighted against the benefits.
Particularly, for robotic systems several tests should be sequentially performed to verify
different features of the device. Testing certain features of the device may be more important
than others. The method to achieve this is presented below:
Test the behavior of the device over time, and if it is capable of maintaining its
characteristics and performance. When used under usual conditions and properly maintained
according to the manufacturer’s instructions, the characteristics and performance of the device
shall not be adversely affected by its lifetime or stresses to which it has been subjected during its
use. Since the device that we are studying was designed and manufactured to be used especially
outdoor, one possible way to run this test is to use it on the streets for different periods of time,
as well as on different streets and places in general so that the device can be subject to distinct
environmental and physical conditions (for instance, different weather conditions, and different
types of floor, respectively). Different devices in distinct stages of life (one device manufactured
in the previous week and other one manufactured one year ago, for instance) shall also be
compared under the same conditions of use, so that the loss of any characteristic or any decrease
in the performance quality can be detected.
Test whether the characteristics and performance of the device are adversely affected
during its transport and storage (through fluctuations of temperature and humidity, for instance),
taking into account the instructions and information provided by the manufacturer.
In order to perform this test, and to see whether it is possible to avoid these problems, the design,
the manufacture processes and the chosen packaging of the device shall be analyzed. To run this

43
test the device shall be transported several times to distinct places and environments. This
transport shall be done having the device in its both packed and unpacked forms (to see if the
chosen packaging is in fact efficient or not), as well as using different methods (such as private
and public transports, and even in more and less careful ways). After each transport, the
conditions of the device shall be verified (both external and internal conditions – just by looking
to the companion robot to look for any kind of damage, and by testing its performance,
respectively).
Test the chemical and physical properties of the device. The design and manufacture of
the device shall pay particular attention to: the choice of materials and substances used (to avoid
characteristics such as toxicity and flammability); and the impact of processes on material
properties (particularly on relevant mechanical properties such as, strength, ductility, and
resistance to wear and fatigue). To run this test, the list of components presents in the materials
used to manufacture the device shall be carefully verified, and after that, the device shall be
placed in different environments and subjected to different substances, which may trigger any
toxic or flammable reaction. The use of the device under higher temperatures, and even close to
fire shall also be tested. Then, mechanical tests shall also be performed, especially to assay the
levels of resistance of the device to fatigue and fracture. First, in order to test the fatigue and
wear resistance of the robot, it shall be used for long periods of time, and once again, under
different environmental and physical conditions. Secondly, to assay its fracture resistance,
different impact, strength and ductility tests shall be conducted, using, for instance, tensile
testing machines (tensometers), or simply replicating normal situations that may occur during its
daily use, such as the accidental fall of the robot on the floor. After this, the performance of the
robot shall be tested once again and compared to previous performances (before being subjected
to these tests).
Test whether the characteristics and performance of the device are adversely affected
by the unintentional ingress of liquids or substances into it, or simply by coming into contact with
these, taking into account the environment in which it is intended to be used. Since the
companion robot is intended to be used outdoor, in order to perform this test, the device shall
be used on the street under different weather conditions, for instance, under the rain or even
snow. Simple tests replicating accidental events, like spilling a certain liquid on the robot shall
also be carried out. After this, the performance of the device shall be tested and compared to
previous performance characteristics (before coming into contact with liquids in this case).
Test whether the design and manufacture processes of the device eliminate or reduce as far as
possible unintended cuts and pricks, as well as it allows easy and safe handling. To run this test,

44
we can simply look at the robot and try to look for defects and sharp tips on its material and its
contours, as well as to verify if it has some kind of handles that facilitate its transport.
Test whether the performance of the device is adversely affected by the presence of
reasonably foreseeable external influences or specific environmental conditions. In order to
assay this problem and run the test, the device shall be placed under external influences (such as
magnetic fields, external electrical and electromagnetic effects), while both turned on and off.
After this, the performance of the robot shall be compared to the previous ones, in order to verify
if it has lost some of its capacities, or even if the accuracy in its measurements (regarding the
location tracking, for instance) has been affected.
Test whether the performance of the device is adversely affected by possible negative
interaction between software and the IT environment within which it operates and interacts. In
order to perform this test, the device shall be used under different IT environments, as well as in
the presence of possible external influences that may disturb the system. After doing this, the
obtained performances shall be analyzed and compared, so that any small differences can be
detected, and consequently any possible negative interaction between these and the device.
Test whether the capacity of maintenance, adjustments, and calibration of the device can
be done in a safe and effective way, and whether these are adversely affected over time
(particularly by the possible loss of accuracy on the location tracking or on other control
mechanism). To run this test, the methods chosen by the manufacturer to perform the
adjustments and calibrations shall be assayed and carefully analyzed in order to understand if
they can be easily and safely performed by any kind of user. After carrying out the calibration
processes, the performance of the device shall be tested and compared with previous
performances, in order to check if these were actually effective. These tests shall also be
undertaken using different robots in distinct stages of life, followed by the analysis and
comparison of their performances, so that any possible loss of accuracy on the location tracking
or on other control mechanism be detected.
Being the robotic system a device which incorporates electronic programmable systems,
including software, it is important to test whether its design ensure repeatability, reliability and
performance in line with their intended use. The solutions adopted to eliminate or reduce as far
as possible the risks or impairment of performance resulting from a single fault condition, shall
also be tested. In order to perform these tests, the device shall be used repeated times,
according to the instructions of the manufacturer and its intended purpose. This shall be done
under different conditions, being that, for the same condition, the exact same test is perform
several times. After doing this, the obtained performances shall be carefully analyzed and

45
compared, in order to look for the repeatability and reliability of the software and its
performance.
Test whether the terminals and connectors to the electricity (used to charge the device,
for instance) are designed and constructed in such a way that minimize all possible risks when
handling it. This test can be performed by simply look, handle and transport the companion
robot, and finally try to use the existent terminals and connectors. After that, based on these
experiences it is possible to conclude if they are in fact safe or not.
Test whether the accessible parts of the device and their surroundings attain potentially
dangerous temperatures under normal conditions of use. In order to run this test, the robot shall
be used under normal conditions, but for long periods of time. After this, the temperature of the
device shall be measured and compared with the ones measured both in a turned off stage, and
after short time uses, in order to understand if the time of use can cause heating of the device
and its components (such as its battery), and more importantly whether it can reach overheating
situations.
Test whether the device was designed and manufactured in such a way that the
information and instructions provided by the manufacturer can be easily understood and applied
by lay persons. In order to conduct this test, it is necessary to look for the existence of label and
instructions for use, and check if these can be understood by any type of user. The existence of
procedures to inform the user that, at the time of use, the device will perform as intended by the
manufacturer, as well as, to warn if the device has failed to provide a valid information or answer,
shall also be verified.
Test the design and manufacture of the device, and check whether the device is being
accompanied by the information needed to its identification and its manufacturer, and by any
safety and performance information relevant to the user. After performing all the necessary
tests, and knowing all the risks that are not possible to eliminate, it is important to verify whether
the device has some protection measures (such as, any kind of information for the users training,
and their safety – warnings, precautions, and contra-indications). In addition, after carrying out
the tests and being aware of the important information that should be provided to the user,
regarding safety and performance of the robot, it is essential to check if these are in fact
accessible to everyone. Thus, it is necessary to verify if this information is contained on the
appropriate places, which are: on the device itself, on the packaging, in the instructions for use,
or, when applicable, on the website (in this case it is also important to ensure that the information
provided is updated). This can be done by simply look for this information in the referred places.

46
References
[1] http://www.omg.org/spec/UML/About-UML/;
[2] REGULATION (EU) 2017/745 OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 5 April
2017on medical devices;
[3] GUIOCHET J., Hazard analysis of human-robot interactions with HAZOP-UML, 9 Feb 2016, HAL
archives-ouvertes, [Online] https://hal.archives-ouvertes.fr/hal- 01271565/document;

Robotic Assistance for Orientation Disease

Recommended

Recommended

More Related Content

Similar to Robotic Assistance for Orientation Disease

Similar to Robotic Assistance for Orientation Disease (10)

More from Luís Rita

More from Luís Rita (20)

Recently uploaded

Recently uploaded (20)

Robotic Assistance for Orientation Disease