experience with a model-based safety analysis process for

Experience with a Model-based Safety Analysis Process

for an Autonomous Service Robot

Damien Martin-Guillerez, Jérémie Guiochet, David Powell

The Seventh IARP Workshop on Technical Challenges for Dependable Robots in Human Environments June 16-17, 2010, LAAS-CNRS (Toulouse, France)

An Autonomous Service Robot: The MIRAS Robot

D. Martin-Guillerez – “Experience on Analyzing Safety of a Service Robot” 2

Building a safe system…

  Building a zero-risk system is impossible   Totally correct specification

  All hazardous situations predicted   All hazardous situations correctly handled

  Totally correct design

  But…   Justified confidence that the specification covers the most

hazardous situations   Justified confidence that the design includes adequate protection

techniques


Building a safe system…

  Safety: absence of unacceptable risk

  Safety analysis process: identify risk and reduce it if not acceptable


Classical risk management process

5

  ISO/IEC Guide 51 & ISO/IEC Guide 73

D. Martin-Guillerez – “Experience on Analyzing Safety of a Service Robot”

Model-based safety analysis methods

6

  Predictive safety analysis requires a system model   Little work on specification or requirement

modelling and safety analysis   Mainly research papers   Languages and techniques difficult to understand for non-specialists

  Applicability of existing model-based methods to safety critical autonomous systems is limited due to:

  Unstructured environment Infinite operation conditions   Decisional layer Non-deterministic behaviour   Human factors Rarely integrated in classical methods


Our proposal

7

  Adapt the classical risk management process by using UML (Unified Modelling Language) to model the system, including the user

  Why UML?   De facto standard   Use case and sequence diagrams are easily understandable by

non-experts   Diagrams can also be used for development process   Models include the user


Outline

  Methodology   Application in the MIRAS project   Conclusions


Outline



Hazard List

Recommendations

Preliminary Hazard list

Operational Hazard list

ISO/IEC GUIDE 51:1999(E)

4 © ISO/IEC 1999 – All rights reserved

5.3 Tolerable risk is achieved by the iterative process of risk assessment (risk analysis and risk evaluation)and risk reduction (see Figure 1).

Figure 1 — Iterative process of risk assessment and risk reduction

6 Achieving tolerable risk

The following procedure (see Figure 1) should be used to reduce risks to a tolerable level:

a) identify the likely user group(s) for the product, process or service (including those with special needs and theelderly), and any known contact group (e.g. use/contact by young children);

b) identify the intended use and assess the reasonably foreseeable misuse of the product, process or service;

c) identify each hazard (including any hazardous situation and harmful event) arising in all stages andconditions for the use of the product, process or service, including installation, maintenance, repair anddestruction/disposal;

d) estimate and evaluate the risk (see Figure 1) to each identified user/contact group arising from the hazard(s)identified;

Use case

diagrams

Risk ListMinimal cut sets

and risk estimation

UML Modelling

PHA (Preliminary

Hazard Analysis)

HAZOP-UML

(HAZard OPerability)

FTA

(Fault Tree Analysis)

Ris

k A

na

lysis

Risk reduction

policies application

Sequence

diagrams


10

Vue globale du processus de gestion du risque dans MIRAS

Step 1: Definition of intended use with UML

  Use cases   Describe the intended use

of the robot   Completed with conditions

  Sequence diagrams   Describe nominal scenarios

corresponding to the use cases

  Messages are either actions (self-message) or interactions


Step 2: Hazard identification

  PHA (Preliminary Hazard Analysis)   Brainstorming meeting with the various stakeholders

  Fast and easy to perform   Identify:

  Major environmental hazards   Standard hazards related to machines

  HAZOP-UML (HAZard OPerability for UML)   Systematic application   Identification of operational hazards

  The two methods are complementary:   PHA: top-down   HAZOP-UML: middle-out


Step 2: Hazard identification HAZOP principle

  Element X Guideword = Deviation   E.g., Pressure X More = “too much pressure”

  Adaptation to UML use cases and sequence diagrams

(Martin-Guillerez et al. 2010) D. Martin-Guillerez, J. Guiochet, D. Powell, C. Zanon, A UML-based method for risk analysis of human-robot interaction, SERENE Workshop, London, UK, 2010


System

No/None Complete negation of the design

No part of the intention is achived and

nothing else happens

More Quantitative increase

Less Quantitative decrease

Step 2: Hazard identification HAZOP tables


Date:

Prepared by:

Revised by:

Approved by:

Line

NumberElement Guideword Deviation

Use Case

Effect

Real World

EffectSeverity

Possible

Causes

Integrity Level

Requirements

New Safety

RequirementsRemarks

Hazard

Number

Use case name:

Project:

Use case description

22/09/13

HAZOP table number: Damien Martin-Guillerez

Entity:

Step 2: Hazard identification HAZOP guidewords adaptation to UML


Entity = Sequence Diagram

Attribute Guideword Interpretation

No Message is not sent

Other than Unexpected message is sent

As well as Message is sent as well as another message

More than Message sent more often than intended

Less than Message sent less often than intended

Before Message sent before intended

After Message sent after intended

Part of Only a part of a set of messages is sent

Predecessors / successors during

interaction

Reverse Reverse order of expected messages

As well a s Message sent at correct time and also at incorrect tim e

Early Message sent earlier than intended time Message timing

Later Message sent later than intended time No Message sent to but never received by intended objec t Other than Message sent to wrong object As well as Message sent to correct object and also an incorrect object Reverse Source and destination objects are reversed More Message sent to more objects than intended

Sender / receiver objects

Less Message sent to fewer objects than intended

Step 3: Risk estimation Estimate severity and likelihood of possible harms

  First iteration of the process   Impossible to precisely estimate the risk (preliminary design)   Preliminary Safety Integrity Level

  Further iterations of the process   Occurrence estimation using FTA (Fault-Tree Analysis)


Num. Severity Type of injury SIL

0 None None 0

1 Minor Superficial injury 0

2 Moderate Recoverable 0

3 Serious Possibly recoverable 1

4 Severe Not fully recoverable without care 2

5 Critical Not fully recoverable with care 3

6 Fatal Not survivable 4

Step 4: Risk evaluation Decide if the risk is acceptable or not

  Application to innovative projects   Several versions of the robot : e.g, development, evaluation, final

(MIRAS)   Risk acceptance criteria depending on the version


10 A Safety Strategy for Rehabilitation Robots 181

10.3 Case Study on Safety of Rehabilitation Robots

In general, the risk assessment and the risk reduction of machinery are carried outaccording to ISO/TR 12100-1 “Safety of machinery-Basic concepts, general prin-ciple for design” and ISO 14121:1999 “Safety of machinery-principles of risk as-sessment”. In Japan, the special committee for standardizing rehabilitation robotshas been established by the Japan Robot Association in 2001. The committeemembers, who are researchers of medical and rehabilitation robots, carried outCase Study of assessing several medical and rehabilitation robots according toISO/TR 12100-1:1992 and ISO 14121:1999. The aim of this case study is to clar-ify the key points of risk assessment and risk reduction for these robots. The fol-lowing medical and rehabilitation robots are carried out case study of the risk as-sessment by use of block chart shown in Fig. 10.3 which is Fig. 10.2 modified byISO14971, that is "Medical devices: Application of risk management to medicaldevices".

Fig. 10.3. The iterative process to achieve safety which is Fig. 10.2 modified by ISO 14971

• Medical robotso Neurosurgical roboto Laparoscopic surgery roboto Continuous passive motion device (CMP)

Step 5: Risk reduction Change the system to reduce its associated risk

  Types of recommendations   Design Additional protection   Use Define rules of allowed usage

  Application of recommendations   Coming from hazard identification and risk estimation steps   According to the version label issued in the risk evaluation step


Outline



The MIRAS project: A robotic strolling assistant

  Goal   Help in standing up, walking

and sitting down   For people suffering from

gait and orientation problems

  Means   Motorised base and moving

handlebar   Sensors to detect patient’s

position and health condition


Results in the MIRAS project

  First iteration of the process   11 use cases, 12 sequence diagrams   13 hazards identified   29 recommendations

  Now design of the MIRAS robot   12 recommendations already applied   Modification of the UML models

  4 new use cases and 4 new sequence diagrams   Modification of one use case and its associated sequence diagram

  Second iteration of the process on the new UML model


Extract of proposed risk reduction in MIRAS

Hazardous situation Risk reduction techniques Type Applied

Robot out of power during strolling Switch to safe mode when battery falls below x% of its charge

Design ✔

Sudden fatigue of the patient General failure of the robot

Design a seat on the robot Use ✔

Patient’s hands are pinched between a table and the handles

Protect hands by curving the handles Design ✔

The patient goes backward to sit down but cannot see her destination

Sitting down operation was redefined. UML Models modified.

Use ✔

General failure of the robot outside medical staff range of sight

Regular network heartbeat. Alarm on message absence Design ✔


Second MIRAS robot design

  New use cases   Sitting down on the robot’s

seat   Getting up from the robot’s

seat   Using the robot as an

motorized wheelchair   Pushing an object using the

robot

  Redefinition of the Sitting down operation


Outline



Method evaluation


  Integrability with the development process   Shared UML models   Parallel safety analysis

  Usability   Low overhead

  few hours sessions with all the experts   few weeks for the overall analysis by the safety expert

  UML-HAZOP book-keeping helped by a CASE tool   Validity

  PHA identifies the classical machinery hazards   UML-HAZOP identifies the major operational hazards due to new

technology   Applicability

  Hazard and recommendation lists have been validated by robotic experts

  Recommendations applied by the experts

Next steps


  Complete the second iteration of the process   HAZOP analysis of the second design (done)   FTA for risk estimation (not started)

  UML statechart model of the robot   HAZOP deviation of the statechart (under study)   Development of a method for the automatic generation of

deviations of scenarios, may be based on statechart modelling (not started)

Thank you for your attention.

Questions?


Why UML, PHA and HAZOP ?

28

  UML (Unified Modelling Language)   De facto standard   Usage diagrams (Use case and sequence diagrams) are easily

understandable by non-experts   Diagrams can also be used for development process   Inclusion of the user in the models

  PHA (Preliminary Hazard Analysis)   Fast and easy to perform   Enables identification of main hazards

  HAZOP (HAZard OPerability)   A well-known technique (70’s)   Identifies hazards and proposes recommendations with low-level

details on the design


Step 2: Hazard identification HAZOP process adaptation


Example of UML-HAZOP application (2)


HAZOP guidewords adaptation for UML use case

Entity = Use Case

Attribute Guideword Interpretation No/non e The condition is not evaluated and can have any valu e

Other than The condition is evaluated true whereas it is false The condition is evaluated false whereas it is true

As well as The condition is correctly evaluated but other unexpected conditions are true

Part of The condition is partially evaluated Some conditions are missing

Early The condition is evaluated earlier than required (other condition(s) should be tested before) The condition is evaluated earlier than required for correct synchronization with the environment

Preconditions / Postconditions /

Invariants

Late

The condition is evaluated later than required (condition(s) depending on this one should have already been tested) The condition is evaluated later than required for correct synchronization with the environment

31 D. Martin-Guillerez – “Experience on Analyzing Safety of a Service Robot”

UML sequence diagram attributes


HAZOP guidewords adaptation for UML sequence diagram

Entity = Sequence Diagram

Attribute Guideword Interpretation

No Message is not sent

Other than Unexpected message is sent

As well as Message is sent as well as another message

More than Message sent more often than intended

Less than Message sent less often than intended

Before Message sent before intended

After Message sent after intended

Part of Only a part of a set of messages is sent

Predecessors / successors during

interaction

Reverse Reverse order of expected messages

As well a s Message sent at correct time and also at incorrect tim e

Early Message sent earlier than intended time Message timing

Later Message sent later than intended time No Message sent to but never received by intended objec t Other than Message sent to wrong object As well as Message sent to correct object and also an incorrect object Reverse Source and destination objects are reversed More Message sent to more objects than intended

Sender / receiver objects

Less Message sent to fewer objects than intended

33 D. Martin-Guillerez – “Experience on Analyzing Safety of a

Service Robot”

HAZOP guidewords adaptation for UML sequence diagram (2)

No/non e The condition is not evaluated and can have any value (omission )

Other than The condition is evaluated true whereas it is false, or vice versa (commission)

As well as The condition is well evaluated but other unexpected conditions are true Part of Only a part of condition is correctly evaluated Message condition

Late

The condition is evaluated later than required (other dependent condition(s) have been tested before) The condition is evaluated later than correct synchronization with the environment

No/Non e Expected parameters are never set / returned

More Parameters values are higher than intended

Less Parameters values are lower than intended

As Well As Parameters are also transmitted with unexpected ones

Part of Only some parameters are transmitted Some parameters are missing

Message parameters / return parameters

Other than Parameter type / number are different from those expected by the receiver

34 D. Martin-Guillerez – “Experience on Analyzing Safety of a Service Robot”

Motivations

35

  Related work on model based/driven safety analysis methods and tools:   Based on design models with different description

languages (e.g., Statemate, SCADE, Altarica, etc.)   Perform automatic analysis (sequence generation, fault tree and

FMEA synthesis, model checking, etc.)   Many associated tools (Cecilia OCAS ©Dassault, HIP-HOPS © Univ.

of Hull., Statemate STSA © IBM, COMPARE © FBK, etc.)


experience with a model-based safety analysis process for

Documents