Jérémie Guiochet

Damien Martin-Guillerez

David Powell

Experience with Model-Based User-Centered Risk Assessment for Service Robots

Keywords: Risk assessment, safety, UML, HAZOP, autonomous systems, service robot

Safety is now a major concern in many computerbased systems and more particularly for autonomous systems such as service robots in physical contact with humans. The traditional approach to analyze the safety of such systems is to use risk assessment methods based on models of system structure, or system behavior. Unfortunately, such models are hard to produce for autonomous systems. We propose an approach based on the standardized risk assessment process which is applied during the initial phases of the development process. We first use the common Unified Modeling Language (UML) and a preliminary application domain hazard analysis without considering any robotic device. Then, during the specification phase, a risk assessment of the robotic system is carried out. It consists in modeling tasks in UML, identifying hazardous situations (including human errors), and estimating associated risks. We base this analysis on an adaptation of the guideword-based collaborative method HAZOP (HAZard OPerability) applied to UML models. The process has been successfully applied to the development of an assistive robot providing assistance for standing up, sitting down and walking, and health-state monitoring. Results in terms of integrability, usability, validity and applicability of the method are really encouraging. Majors benefits are a good management of the level of abstraction (and thus combinatory explosion is controlled), an easy communication between different stakeholders using basic UML diagrams, and a structured safety documentation required for certification.

I. INTRODUCTION

Safety is now a major concern in many computer-based systems and more particularly for autonomous systems such as service robots in physical contact with humans. The traditional approach to analyze safety of such systems is to use risk analysis methods such as Fault Tree Analysis (FTA) or Failure Mode, Effects, and Criticality Analysis (FMECA). Those methods are usually based on representations of the system such as block diagrams for functional structure, and automata for dynamics. However, such models are inadequate for autonomous systems. First, the decisional software of such systems cannot easily be decomposed into functional blocks. Second, automata are not suitable for modeling the dynamics of goal-driven deliberative systems [START_REF] Gunderson | Chapter 10 -Deliberative System[END_REF] that operate autonomously within an unstructured environment, that may include human beings. Moreover, the fact that environment is not structured means that the number of operating conditions is essentially infinite, which leads to a combinatory explosion using classic risk analysis methods.

We propose an approach to cope with these issues through the combination and adaptation of several well-known techniques. The proposed approach is driven by two important considerations: it is limited to the initial phases of the development process (Requirement Elicitation phase and Specification phase) and it is based on a standardized risk assessment process. In recent standards [START_REF]Risk management -risk assessment techniques[END_REF], it is composed of risk analysis (definition of intended use of the system, hazard identification, and risk severity and probability estimation) and risk evaluation (decision as to whether the risk is acceptable or not). The process is usually performed iteratively, in parallel with the development process. A recent trend is for risk assessment to be based on the same models as those used for system development. Thus, we adapt this classic risk assessment process to a concrete and usable model-based approach, which integrates some human factors activities.

During the Requirement Elicitation phase, we describe scenarios of use with the de facto standard Unified Modeling Language (UML [START_REF]OMG Unified Modeling Language (OMG UML), Superstructure, V2.1.2[END_REF]), and analyze application domain hazards without considering any robotic device. Then, during the Specification phase, a risk assessment of the robotic system is carried out. We consider that the earliest models used during system development, usually describe scenarios of use of the system. We claim that the analysis of deviations of such scenarios allows the identification of major hazards. Hence we restrain our approach to UML sequence and use case diagrams. Based on these models, we identify hazardous situations including human errors, and estimate associated risks. This analysis is based on an adaptation of the guideword-based collaborative method HAZOP (HAZard OPerability) [START_REF]Hazard and operability studies (HAZOP studies) -Application guide[END_REF] applied to UML models.

This process has been successfully applied to several robotic projects. We illustrate each step of the process using the MIRAS project [START_REF] Miras | Multimodal Interactive Robot for Assistance in Strolling[END_REF]. which aims to develop an assistive robot for standing up, sitting down and walking, and also capable of health-state monitoring. It is designed to be used in elderly care centers by people suffering from gait and orientation problems where a classic wheeled walker (or "rollator"), such as in Figure 1(a), is not sufficient for patient autonomy. The robotic rollator is composed of a mobile base and a moving handlebar (Figure 1(b)). This paper is structured as follows. We present our general process in Section II. This approach is detailed step by step with its application to the MIRAS project in Section III. In Section IV, we discuss the validity of our approach. We present related work in Section V. Section VI concludes the paper.

II. METHOD OVERVIEW

In this section we give an overview of the process and its activities. The method will be detailed further in section III.

A. Model-based risk assessment

The concept of risk is now widely used in many domains, from financial mechanisms to embedded systems. Several standards provide generic definitions of risk and elements of the risk management process [START_REF]Risk management -risk assessment techniques[END_REF], [START_REF]Medical devices -Application of risk management to medical devices[END_REF]- [START_REF]Risk management -Vocabulary -Guidelines for use in standards[END_REF]. The generallyaccepted definition of risk in the safety domain is the combination of the likelihood of harm and its severity [START_REF]Safety aspects -Guidelines for their inclusion in standards[END_REF]. Tolerable risk is achieved by an iterative process of risk assessment (risk analysis and risk evaluation) and risk reduction (see left-hand part of the Figure 2). This process and its terminology are now quite stable in industrial standards and are widely accepted. In the safety domain, risk analysis aims to identify hazards and estimate the associated risk (i.e., estimate severity and probability of risk). Risk evaluation then consists of comparing the estimated risk against given risk criteria to determine the acceptability of the risk. Risk reduction is a process in which decisions are made and measures implemented with the aim of reducing risks to specified levels. As presented on Figure 2, the process is iterative because for each risk reduction decision it is necessary to estimate if risks are effectively reduced and check that new risks have not been introduced. A point that is usually not mentioned is that this process is also incremental, because it follows the development process, and for each new iteration of the development, another cycle of risk assessment is performed.

When adapting this process, the main challenges are to:

• describe the target of evaluation at the right level of abstraction; • facilitate communication and interaction between different stakeholders involved in the risk assessment process (e.g., in our case, stakeholders are patients, medical staff, and robotics experts); • manage the combinatorics of risk analysis, which often results in an excessive number of documents and models; • document safety analysis results and the assumptions on which these results depend to support reuse and maintenance.

In this context, we base our approach on the generic risk assessment process, in an iterative and incremental approach. The same cycle is repeated until the designed system achieves tolerable risk. It is strongly linked with the development process as it shares the same system description models. For this, we chose a subset of UML. This language was also used to communicate with the stakeholders and organize safety analysis documents. UML is a standard general-purpose modeling language that includes a graphical notation enabling the representation of an abstract model of a system [START_REF]OMG Unified Modeling Language (OMG UML), Superstructure, V2.1.2[END_REF]. This abstract model is composed of different UML diagrams, each of which is a partial graphical representation of the system that concentrates on a particular viewpoint. Two diagrams are commonly used for description of the system usage: use case diagrams and sequence diagrams. Use cases represent intended use of the system and are linked with the actors that can trigger scenarios of the use case. Each use case is further documented by fields such as pre-conditions and post-conditions. Each sequence diagram represents one particular scenario of one use case.

B. Activities during the requirement elicitation phase

During this phase (cf. Figure 2), system analysts define the system requirements in collaboration with users, customers and other stakeholders. This is a wide field of research in system engineering, but we will only deal here with activities related to risk assessment and reduction. We first consider general usage scenarios of the application domain, using UML use case models to describe the various tasks involved. By "application domain", we refer here to the medical domain of rehabilitation (without any robot). For instance, in our case study, we gather knowledge on the use of classic walkers (wheeled or not), and we model it with a use case diagram. This work is then completed with a brainstorming meeting on application domain hazards, and investigations on the severity and probability of occurrence of potential harm. The analysis carried out during this phase provides an important point of reference for assessing the benefits in terms of safety of the new robotic system.

C. Activities during the specification phase

During the specification phase, we transform the application domain models into system models by integrating the robot. This activity, "System modeling & task analysis in UML", is strongly linked with the human factors domain. Indeed, the activity dedicated to the analysis and the allocation of tasks between the robot, the patient and the operators, is a part of task analysis and task allocation, which are two main topics in human factors [START_REF] Stanton | Human Factors Methods: A Practical Guide for Engineering And Design[END_REF]. Task analysis aims to identify the details of specified tasks, including the knowledge, skills, attitudes, and personal characteristics required for successful task performance. During system analysis, this activity is linked to task allocation, which aims to determine the distribution of work between human actors and machines. For instance, it is particularly important to define non-ambiguous and consistent tasks for humans who are using the robot. We choose to represent robot tasks with the UML message concept, which is simple to manipulate and understand, even for non-experts in modeling (such as doctors). Task analysis and task allocation can be considered independently of the risk assessment process, but in case of safety-critical systems with important human-robot interaction (even physical interaction), they are strongly linked, so we include them in our process. The outputs of the first activity of the specification phase consist of system models, which are shared with the development process, and initial remarks and recommendations about inconsistency or preliminary ideas on safety. All these artefacts are then presented and validated during meetings with robotic and medical experts.

The second activity during the Specification phase is hazard identification, which is performed using Preliminary Hazard Analysis (PHA [START_REF] Rausand | System Reliability Theory: Models[END_REF]) and an adaptation of HAZOP (HAZard OPerability [START_REF]Hazard and operability studies (HAZOP studies) -Application guide[END_REF]). PHA is a simple, inductive method of analysis whose objective is to identify the hazardous situations and events that can cause harm. It is most commonly carried out early in the development of a project when there is little information on design details. A list of hazards and generic hazardous situations is formulated during workshops and meetings by considering characteristics such as mechanical parts of the robot, hardware, software, robot's human and physical environment.

It also produces a list of recommendations. Through the HAZOP method, a system is analyzed by holding a review of the systematic generation of deviations defined by the conjunction of parameters of the system (e.g., pressure, temperature...) and guidewords (e.g., no, more, less...). We apply PHA in a classic way but we adapt the HAZOP method to apply it to UML use cases and sequence diagrams (see HAZOP-UML [11] [12]). This activity produces a large amount of data, from which we extract a list of hazards and recommendations. One important point is that we use both techniques (PHA and HAZOP) because they are complementary. Indeed, PHA is a top-down approach through which analysts directly identify hazardous situations and then potential sources, whereas HAZOP is more bottomup, i.e., analysts identify misbehavior sources and then consequential hazardous situations.

Risk estimation is then carried out. By definition, it should consist in estimating severity and probability of occurrence of each potential harm. For that, the probability of hazardous situations needs to be estimated. Quantitative and even qualitative estimations of probability are unfortunately usually impossible at an early design stage, mainly due to the lack of data on human or software failure rates, or even on functional parts that have not yet been developed. It is nevertheless important to identify serious weaknesses of the system specification. Consequently, we base our risk evaluation at this stage on just the severity of the potential harm (a similar approach is considered in [START_REF] Hole | Toward risk assessment of largeimpact and rare events[END_REF] when assessing the risks of rare large impact events in securitycritical systems). A harm severity level is thus estimated for each hazard potentially inducing that harm (see Table I. This leads to two outputs. First, critical functions are identified and assigned a required integrity level, using the concept of Safety Integrity Levels (SIL) 1 in the IEC61508 standard [START_REF]Functional safety of electrical/electronic/programmable electronic safety-related systems[END_REF]. Second, it produces a list of hazards and hazardous situations ranked according to their severity.

The next two activities (risk evaluation and risk reduction, cf. Figure 2) will not be presented in detail in this paper since at this stage in the development process they essentially depend on discussions and agreements between robotics experts and doctors. Indeed, risk evaluation, as it was mentioned before, is the decision of the acceptability of the risk. As we will see later in section III-E, our decision of acceptability of risk depends on the development version of the robot (development version, clinical evaluation version and final version). The risk reduction activity is the application of recommendations, and its integration in mechanical design for instance. This is carried out by the robotic and integration team of the project. 1 A SIL in the IEC61508 standard [START_REF]Functional safety of electrical/electronic/programmable electronic safety-related systems[END_REF] corresponds to a level of confidence that can be accorded to a function or a component to operate correctly. It maps to a failure probability or rate with respect to hardware faults and to prescribed defences against software faults.

D. Risk assessment and reduction in other phases of the development process

We actually performed more iterations than those presented here (Requirement Elicitation and Specification), but we focus on the two first iterations in this paper partly due to space limitation but above all because it is during these iterations that most of the risk is identified and treated. During subsequent specification iterations, UML models are refined and the HAZOP analysis is updated. In later phases, which are outside the scope of this paper, we use Failure Mode, Effects, and Criticality Analysis (FMECA) and Fault Tree Analysis (FTA) to assess the detailed design.

III. RISK ASSESSMENT AND REDUCTION PROCESS

ACTIVITIES

In this section, we detail the various activities of our risk assessment process. They are illustrated by their application in the MIRAS project. We present the activities performed during the first two phases of the development process: Requirement Elicitation and Specification.

A. Application domain modeling and associated hazard identification during Requirement Elicitation

We first model the application domain tasks without the robotic system (i.e., using a classic walker, or a "rollator" with UML use case diagrams (Figure 3(a)). During this step, application domain modeling increases the understanding of the domain and facilitates communication, particularly between engineers and doctors. In the next phase (Specification) this model will be reused to define tasks allocated to the robot and to the patient. For each use case, a textual description specifies more precisely the possible scenarios and their conditions of execution. Even if the use case strolling seems to be the most important for the design, other use cases which can later be critical for safety have to be analyzed. For example, while walking, the patient can push an object (for instance a door) with the walker. The future system should allow all use cases to be carried out safely, and particularly that one.

Hazard identification in this phase was carried out with brainstorming sessions or during meetings with doctors. We The only studies that could be found focused on patient falling consequences, with hardly any statistical data. So we performed the analysis using generic hazard tables and discussions with doctors. We do not give the complete list here, but we used tables of generic hazards, such as in ISO14121 [START_REF]Safety of machinery -risk assessment -part1 principles[END_REF] (safety of machinery), to classify identified hazards according to four types : mechanical hazards (cutting edge, unstable structure, brake failure, flat tire, wheel blocked), hazards generated by neglected ergonomic design (unhealthy postures or excessive forces, patient feet collision with wheels, lateral movements impossible, fingers pinched by hand-brakes, handbrakes too hard to press), human errors (falling, release of the two handles, walking in hazardous places like stairs) and hazardous environmental conditions (holes, low obstacles, slippery floor).

Despite lack of documented knowledge of walker accidents (other than falling), the standard on (non-robotic) rollators ISO 11199 [START_REF]Walking aids manipulated by both arms -requirements and test methods -part 2: Rollators[END_REF] gives very useful guidance for reducing probability or severity of harm by defining prescriptive requirements (e.g., for stability).

B. System use modeling & task analysis in UML

In this activity, we define the use cases of a robotic system (Figure 3(b)) and then merge with the use cases of a classic rollator (Figure 3(a)). This led us to modify the specifications of the previous use cases and identify new actors. Use cases can be described graphically, but the most usable tabular textual description will be used here. The use cases are completed by textual conditions of use: preconditions to be fulfilled before any action of the use case can be performed, postconditions to be satisfied at the end of the use case, and invariants that must hold during the use case.

For instance, in the MIRAS project, we identified 13 use cases: Strolling (UC01), Standing up operation (UC02), Sitting down operation (UC03), Balance loss handling (UC04), Summoning and autonomous movement of the robot (UC05), End of use detection and moving to a waiting position (UC06), Positioning the robot by hand (UC07), Alarm handling (UC08), Patient profile programming (UC09), Patient

Table II UC02 "STANDING UP OPERATION"

Use case name UC02. Standing up operation Abstract

The patient stands up with the help of the robot Precondition

The patient is sitting down The robot is waiting for the standing up operation Battery charge is sufficient to do this task and to help the patient to sit down The robot is in front of the patient Postcondition The patient is standing up

The robot is in admittance mode

Invariant

The patient holds both handles of the robot The robot is in standing up mode Physiological parameters are acceptable profile learning (UC10), and Robot setting-up (UC11), Pushing an object with the robot (UC12), Use robot for transfer operation (UC13). All use cases from domain application (cf. Figure 3 Furthermore, they can be included as part of the documentation for the certification process. Sequence diagrams are highly expressive yet can remain quite simple when used to describe use scenarios. This simplicity makes them an attractive support for hazard identification by deviation analysis since it helps to keep the combinatorial aspects of such analysis under control. Throughout the modeling process, preliminary safety remarks and recommendations can be issued.

C. PHA and HAZOP-UML

To identify hazards that can arise from the use of the robot, we used two complementary techniques: Preliminary Hazard Analysis (PHA) and HAZOP-UML (a method combining the HAZard OPerability technique with UML). To carry out our Preliminary Hazard Analysis, the various stakeholders of the project meet together for several workshops (two in the MIRAS project). During the workshops, participants try to consider all the possible causes of hazards in the system (e.g., environmental, electrical, mechanical, hardware/software and human). For each cause, the participants identify the hazards that can arise. In the MIRAS project, the PHA led to the identification of 45 hazards (see

PHA Hazards

Wet ground / Risk of grip loss Electrical current drop / Risk of sudden reboot with wrong parameters.

Project: MIRAS

Number Category Hazard

an extract in Table III).

We then apply the HAZOP-UML method, which adapts the HAZOP [START_REF]Hazard and operability studies (HAZOP studies) -Application guide[END_REF] method to analyze deviations of the UML use case and sequence diagrams. According to the Defence Standard 00-58 [START_REF]HAZOP studies on systems containing programmable electronics[END_REF], HAZOP analysis is the systematic identification of every deviation of every attribute of every entity. Each deviation is a potential hazard that can lead to a harmful event. We adapted the guideword lists to apply them to attributes of use cases and sequence diagrams. The guideword list we use for the use case entity is given in Table V and an extract of the analysis of UC02 (Standing up operation) is presented in Table VII. All guidewords are applied to generate deviations. The analyst then establishes the effect at the use case level, and the result in the real world. The other columns of the table guide the analyst to establish a severity level, to deduce requirements and otherwise make remarks on that deviation. The complete method is presented in [START_REF] Martin-Guillerez | A UML-based method for risk analysis of human-robot interactions[END_REF]. As the choice of guidewords has also been done integrating human error models, the The conjunction attribute + guideword facilitates the generation of deviations. We adapted the guidewords of Erreur ! Source du renvoi introuvable. according to the two types of entities. They are presented hereafter in tabular form. Each table associates a list of guidewords for an attribute of one entity. An interpretation of the generic deviation is also provided in order to guide the mental process. Table 3 is the adaptation of the HAZOP guidewords for use cases, and Table 4 for sequence diagrams (which is an extension of the results of Lano et al.

Table V ATTRIBUTES, GUIDEWORDS AND INTERPRETATIONS FOR USE CASE ENTITY IN THE HAZOP-UML METHOD

[LAN02]).

Entity = Use Case

Attribute Guideword Interpretation

No/none The condition is not evaluated and can have any value

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

Table 3 -Attributes, guidewords and interpretations for use case entity

Table VI EXTRACT OF RECOMMENDATIONS ISSUED DURING THE HAZOP-UML ANALYSIS (26 TOTAL)

Dev Eval Final

Rec1

The standing-up profile should be validated by a human operator

!

Rec2

Worst-case electrical consumption must be evaluated beforehand (and display of the mean battery time left by the robot)

!

Rec22

Send regularly a network heartbeat from the robot to the medical staff control panel. Launch alarm on time-out.

!

Rec31

Safety margins should determined for maximum and minimum height of the robot (monitoring is required)

! !

Prepared by:DMG Project: MIRAS HAZOP Recommendations 28/10/09

Number Description Version scope

Revised by: JG HAZOP tables also include the analysis of human errors. An important point is that human errors are analyzed in wellidentified scenarios of use, showing also system response, which is not the case in many human error analysis methods (see [START_REF] Stanton | Human Factors Methods: A Practical Guide for Engineering And Design[END_REF]).

In the MIRAS project, the analysis of 297 deviations led to the identification of 13 hazard classes (Table IV). This table presents the main hazardous situations of the system. In the HAZOP analysis, each deviation that potentially leads to a hazard class is labeled with the corresponding number (column "Hazard Number", Table VII). Table VI gives an extract of the resulting list of recommendations. This list is derived from the "new safety requirements" column of the HAZOP-UML tables. Actually, recommendations were issued as a result of each step of the risk assessment process. UML modeling, PHA and HAZOP-UML all gave rise to general recommendations.

D. Preliminary risk estimation

As previously mentioned, it is not possible to estimate probabilities for each hazard. Indeed, at this stage of the development, many choices are still not done. Also, it is difficult to estimate failure rates of humans, and software components under development. So, we estimate a severity level for each hazard identified in the HAZOP tables. This level is noted in the severity column of the HAZOP tables (see for instance Table IV, based on the severity level list of Table I). The "Type of Injury" column has been discussed with the stakeholders according to the MIRAS project objectives but this list can be generalized to all service robots.

During the HAZOP analysis we also assign preliminary SILs (Safety integrity Levels [START_REF]Functional safety of electrical/electronic/programmable electronic safety-related systems[END_REF]) to safety related components. To do this, a SIL is mapped to each severity level (cf. Table I, SIL column). Components associated with each HAZOP deviation are then assigned a SIL (cf. Table IV, integrity level requirements column) according to the most severe hazard induced by this deviation (e.g., the patient position detection system should be SIL1).

E. Preliminary risk evaluation

Risk evaluation consists in comparing the estimated risk with given risk criteria to determine the acceptability of the risk. Even if some proposals have been made for acceptability criteria for rehabilitation robots [START_REF] Nokata | A safety strategy for rehabilitation robots[END_REF] there is no set of generally accepted risk acceptance principles. This is an important issue, which addresses political and ethical concerns. Nevertheless, criteria are needed for engineers to determine which risks have to be reduced. In the MIRAS study, after the preliminary risk estimation only considering hazard severity, each hazard and possible recommendations were proposed to the robotics experts. We also compared those hazards to the ones identified in the Requirement Elicitation phase to estimate the benefits of using such a system. On the basis of our risk analysis results, we proposed a classification of risk acceptance criteria according to three versions of the robot: development version for using the robot in the laboratory, evaluation version for the prototype used in hospitals for clinical evaluation in the presence of medical staff, and final version for operational life without medical staff. The classification of risk acceptance criteria was used to determine the applicability of recommendations, as presented in the last three columns of Table VI (Dev, Eval and Final). This classification and the level assignment have been discussed with robotics and medical experts. Discussions have been driven by the tables with traceability notations (not presented here), linking recommendations of this table and covered hazardous situations. For example, recommendation 22 (Rec22 in Table VI), is not required in Dev and Eval versions, because the robot will be always used in the presence of medical or robotics experts.

F. Preliminary risk reduction

Finally, selected risk reduction recommendations were applied to produce a new version of the robot. These recommendations can be classified in the following categories: modification of allowed use (e.g., restricted or forbidden environment), modification of the specification (e.g., behavior of the robot in case of release of the arms by the patient), and modification of the design (mechanical, hardware or software). Some recommendations reduce the severity of the corresponding hazard (e.g., a bumper added to the robot reduces the severity of a collision) while others reduce the probability of occurrence (e.g., infrared sensors to detect the patient's feet will decrease the probability of a collision between the patient and the robot). The second version of the MIRAS robot (Figure 5) includes most mechanical and hardware recommendations issued after the analysis (it also includes several ergonomic changes). Some important recommendations are already included in the design of the second version of MIRAS robot, and other ones are still in discussion with the project's robotics experts 2 . This second version especially meets the requirements asked for the evaluation version of the robot (i.e., a robot that will be used in the laboratory and for clinical evaluation).

IV. EVALUATION OF THE METHOD

We evaluate our approach from four different perspectives: integrability into the development process (sharing of the models, synchronization with development phases), usability, validity and applicability.

Integrability: in our approach, UML design models are shared with the development process. This helps to avoid inconsistencies. In MIRAS, we found it relatively easy to change models following design changes and to trace corresponding hazards. Another benefit is that our safety analysis can be carried out at the beginning of the development, but also during design refinement. However, HAZOP-UML cannot be applied to detailed UML models because of the combinatory explosion of the number of deviations.

Usability: the overhead of using this method in the overall process is reasonable low. For instance, in our Specification phase, apart from the modeling that was shared between stakeholders, the only critical path overhead that was induced were the meetings for hazard identification, risk estimation and evaluation: two workshops of two hours each for the Preliminary Hazard Analysis and two sessions of two hours to present the outcomes of the HAZOP-UML Analysis and the assessed risks. The time devoted to prepare guidelines for PHA workshops (a few hours), the time to carry out the HAZOP-UML analysis (2 weeks) and the time to format the results (a week) resulted in a one-month study. HAZOP-UML already proved to be usable even by hand but would be even more so with a tool to assist traceability and result formatting. We have developed a first prototype of such a tool [START_REF] Martin-Guillerez | A UML-based method for risk analysis of human-robot interactions[END_REF].

Validity: Our approach partly relies on the HAZOP-UML method, which identifies a large set of operational hazards. Other hazards, especially environmental hazards are covered by PHA. Of course, all hazardous situations cannot be foreseen. Nevertheless, using these techniques, all classic hazards of robots (that can be found in standards) were identified and several new hazards were discovered. Other work in the context of MIRAS, based on the analysis of deviations of the behaviour of the robot modeled with state diagrams, has not yet identified any new hazards. This gives us confidence that the coverage of HAZOP-UML and PHA is sufficient to identify most hazards of service robots.

Applicability: the first iteration of our risk assessment process led to conclusive evidence that the first prototype of the MIRAS robot was unsafe. The hazard list and the recommendations issued were accepted by the robotic experts. Our recommendations were taken into account in the design of the second prototype.

V. RELATED WORK

There have been several previous studies aimed at linking model-based development with risk analysis. For instance, in the CORAS project [START_REF] Coras | A platform for risk analysis of security critical systems[END_REF], [START_REF] Bjørn | An approach for model-based risk assessment[END_REF], a framework has been developed to exploit risk analysis and object-oriented modeling concepts, for risk assessment of security-critical systems. We focus on safety rather than on security, but the objectives of our study are quite similar to CORAS. Nevertheless, we do not have the same claims in terms of UML diagrams (we only focus on use case and sequence diagrams) and risk analysis techniques (we only focus on HAZOP). A major difference is that we strongly interconnect UML models and techniques such as HAZOP whereas that is not the case in CORAS. For instance, they use HAZOP without any real link with UML models (their HAZOP guidewords are not applicable to UML elements). Actually, they identify critical assets and analyse deliberate/unintentional manipulation of these assets [START_REF] Winther | Security assessments for safety critical systems using hazops[END_REF]. In safety, the entities of interest are system's users and environment rather than system assets. Hence, their approach is hardly applicable for safety analysis [START_REF] Bjørn | An approach for model-based risk assessment[END_REF].

Our risk analysis approach is based on a re-interpretation of HAZOP guidewords in the context of certain UML models. The proposal in [START_REF] Lano | Safety and security analysis of object-oriented models[END_REF] followed by a more systematic study in [START_REF] Hansen | Hazop analysis of uml-based software architecture descriptions of safety-critical systems[END_REF], also considers a HAZOP guideword interpretation for the deviations of UML elements such as class, association, classifier role, message, etc. A similar approach was followed in [START_REF] Gorski | Development and validation of a hazop-based inspection of uml models[END_REF] and [START_REF] Jarzebowicz | Empirical evaluation of reading techniques for uml models inspection[END_REF], which also present a statistical analysis of the usability of this method. The guideword interpretation for the static UML diagrams in those studies aims to inspect the model to determine development faults and not to identify operational deviations. Nevertheless, for the UML dynamic diagrams (use case, sequence, activity, and statechart diagrams) many guideword interpretations can be used for exploring deviations during operational life. This is the case in studies presented in [START_REF] Johannessen | Hazard analysis in object oriented design of dependable systems[END_REF] and more formally in [START_REF] Allenby | Deriving safety requirements using scenarios[END_REF], which focus on use cases. The latter study led to a method that has been successfully used in [START_REF] Arlow | Safety specification of the active traffic management control system for english motorways[END_REF] and [START_REF] Frantz | Integrating safety and formal analyses using uml and pfs[END_REF]. This work on use cases also inspired a similar approach for security where new interpretations of guidewords have been proposed [START_REF] Srivatanakul | Security analysis with deviational techniques[END_REF]. Even if this work is more oriented towards malicious behavior of actors, several interpretations can be applied in safety-critical systems with human-machine interactions. We combine and extend the results of those studies, but focus only on use case and sequence diagrams in order to explore deviations during operational life. We also give a particular attention to the integration of HAZOP-like human error analysis techniques as presented in [START_REF] Guiochet | Toward a human-centered UML for risk analysis -application to a medical robot[END_REF]. Indeed, human factors methods [START_REF] Stanton | Human Factors Methods: A Practical Guide for Engineering And Design[END_REF] are a major issue in safetycritical systems but their analysis is often uncorrelated with preliminary system modeling activities. On the contrary, a key point of our approach is to consider human factors from the outset, by including them in model-based risk analysis.

VI. CONCLUSION

To tackle safety of autonomous systems, appropriate analysis methods are needed especially when the system physically interacts with humans. Even if standards and research papers converge on approaches based on risk assessment process, it is still not obvious how to apply such approaches, and to link them with the development process.

We thus adapted the classic risk assessment process to a concrete and usable model-based approach, which integrates some human factors activities. We presented the activities performed during the first phases of the development process. During the Requirement Elicitation phase we model the application domain tasks performed by the users without any robotic device, and establish a list of application domain hazards. During the specification phase, we model tasks and the system use, and perform risk assessment based on the UML models.

The artefacts produced by the method are a list of hazards, and for each hazard, a list of potential sources. This leads to a list of recommendations, and for each recommendation an applicability level depending on the robot version.

This method presents qualities of integrability, usability, validity and applicability. Majors benefits are: manageability of the level of model abstraction (and thus we control complexity and combinatory explosion), ease of communication between different stakeholders, and a structured safety documentation as required for certification. We are now improving the quality of this method by developing a tool (a first prototype has been developed and presented in [START_REF] Martin-Guillerez | A UML-based method for risk analysis of human-robot interactions[END_REF]), that provides assistance for drawing UML diagrams and HAZOP tables, checking consistency between models, and producing documentation and reports.

An important drawback is that since our method is applied at the very first steps of the development process, it is impossible to collect data for estimation of probability of harm occurrence. This leads to an approach essentially driven by severity levels, considering that all deviations leading to a high severity should be treated. It is then difficult to justify that an acceptable level of risk has been reached. For this reason, we are now working on improving this method by allocating quantitative estimations of probabilities of hazard occurrence, building fault trees from the PHA and HAZOP-UML analyses. Another drawback is that the consequences of deviations are estimated by the analyst without any prescriptive model, and only with descriptive models (sequence diagrams for instance). It is thus strongly dependent on the analyst's expertise. We are now also working on an extension of HAZOP-UML to state-transition diagrams, in order to integrate deviations into the behavior models, so as to automatically identify their consequences.

Figure 1 .

 1 Figure 1. From classic walker to robotic assistant

Figure 3 .

 3 Figure 3. Application domain use cases

  (a)) can be found here, but new extensions of use result in new use cases (UC02 to UC06 for instance). A generic robotic use case like Task programming from Figure 3(b), has been split into two use case : Patient profile programming (UC09), Patient profile learning (UC10). Once all textual description has been done, pre-conditions, postconditions and invariants are identified. By way of an example, Table II lists the conditions of use case UC02 (Standing up operation), We chose to specify tasks and subtasks with the UML concept of messages in sequence diagrams. The sequence diagram of Figure 4 presents as an example the main scenario of the use case Standing up. Sequence diagrams are often used for high-level representations of a system. They are easily understood by the different stakeholders.

Figure 4 .

 4 Figure 4. Sequence diagram UC02.SD01 giving main scenario of UC02 "Standing up operation"Table III EXTRACT OF THE HAZARDS IDENTIFIED BY THE PRELIMINARY HAZARD ANALYSIS (45 TOTAL)28/10/09Prepared by: JG Revised by : DMG

HN7

  Failure to switch to safe mode when a problem is detected. The robot keeps moving. Severe HN1 Incorrect position of the patient during robot use. Serious HN2 Fall of the patient during robot use. Serious HN3 Robot shutdown during its use. Serious HN8 Robot parts catching patient or clothes Serious HN9 Collision between the robot (or robot part) and the patient. Serious HN10 Collision between the robot and a person other than the patient. Serious HN11 Disturbance of medical staff during an intervention Moderate HN12 Patient loses her balance due to the robot Moderate HN13 Patient fatigue Minor

Figure 4 -

 4 Figure 4 -HAZOP methodology adapted from [MoD Def Stan 00-58:2000]

Figure 5 .

 5 Figure 5. Mechanical design of the second prototype of the MIRAS robot

Table I SEVERITY

 I LIST USED IN THE MIRAS PROJECT, DERIVED FROM THE ABBREVIATED INJURY SCALE OF[START_REF] Ais | The abbreviated injury scale[END_REF]

	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

Table IV HAZARD

 IV CLASSES AND THEIR ASSOCIATED SEVERITIES Fall of the patient without alarm or with a late alarm.

	Num. Description	Severity
	HN4

Severe

HN5

Physiological problem of the patient without alarm or with a late alarm. Severe HN6 Fall of the patient caused by the robot. Severe

Table VII EXTRACT

 VII OF THE HAZOP-UML ANALYSIS TABLE OF UC02 "STANDING UP OPERATION"

	Project: MIRAS HAZOP table number: UC02					Use case description		Date: Prepared by:	04/08/09 Damien Martin-Guillerez
	Entity: UC02					Use case name: Standing up operation	Revised by: Approved by:	Jérémie Guiochet
	Line Number	Element	Guideword	Deviation	Use Case Effect	Real World Effect	Severity	Possible Causes	Integrity Level Requirements	New Safety Requirements	Remarks	Hazard Number
											If the robot stops
	15	Battery charge is sufficient to do this task and to help the patient to sit down (precondition)	No/none	Battery charge is too low but the robot starts the standing up operation	The robot interrupts its movement (standing up or walking)	Loss of balance or fall of the patient	Serious	HW/SW Failure Specification error	Battery charge sensors should be SIL2	Worst-case electrical estimation consumption must be of the battery charge evaluated beforehand. Take the lower bound	during standing fall back on the operation, the the patient will most probable scenario is that	2,6
											seat.
	16		Other than	cf L15
	17			Battery charge is high enough but the robot thinks otherwise	Robot refuses to start stand up operation	Patient is confused	None	HW/SW Failure error Specification	None	None

ISIR -Institut des Systèmes Intelligents et de Robotique (http://www.isir.fr) and ROBOSOFT (http://www.robosoft.fr)

ACKNOWLEDGEMENTS

This work was partially supported by the MIRAS Research Project, funded under the TecSan (Technologies for Healthcare) program of the French National Research Agency (French ANR).


Damien Martin-Guillerez

Jérémie Guiochet

David Powell

Christophe Zanon

A UML-based method for risk analysis of human-robot interactions

Keywords: K.4.1 [Computers and Society]: Public Policy Issues-Human safety, K.6.1 [Management of Computing and Information Systems]: Project and People Management-Systems analysis and design, D.2.2 [Software Engineering]: Design Tools and Techniques-CASE Design, Security, Human Factors Safety, risk analysis, scenario, HAZOP, UML

Safety is a major concern for robots that interact physically with humans. We propose a risk analysis method based on deviation analysis of system usage scenarios that allows the identification of major risks. Scenarios are described with the common Unified Modeling Language (UML), and risk analysis is performed with the guideword-based collaborative method HAZOP (HAZard OP-erability). We adapt HAZOP attributes and guidewords for generic interpretation of UML use-case and sequence diagrams describing humanrobot interactions. This approach has been systematically applied for the analysis of two quite different robots working in a human environment: a mobile manipulator and a robotic strolling assistant. When applied, the method gave conclusive evidence that the modeled systems were not safe. A CASE tool to support this method is also presented.

INTRODUCTION

Previously confined to purely industrial applications, robots are now starting to directly interact with humans: assistive robots, medical robots or even pet robots. Such interactions between humans and robots can lead to hazardous situations for the humans, especially for medical robots. Therefore, when designing a robot interacting with humans, methods to analyze the safety of the robot should be used.

Traditional methods to tackle safety like Fault Tree Analysis or Failure Modes, Effects and Criticality Analysis raise different concerns. First, they are unsuited to analyze physical interactions between human and robot. Second, multiple stakeholders using their own languages and models need to share the effort of risk analysis. Traditional methods thus often give rise to consistency errors and understanding problems. Third, risk analysis should start at the very first steps of the development process. We propose a method to address these issues based on two well-known techniques. The Unified Modeling Language (UML) is used to describe the interactions between humans and the robotic system. Risk analysis is then performed on this model with the guidewordbased collaborative method HAZOP (HAZard OPerability). This method is designed to be used at the early stages of system development. Human-robot interactions are first described using UML use-case and sequence diagrams. The main advantages of using UML are that it is now a de facto standard for system description, it is easily understandable by non-experts, and it is well adapted for early stages of development. UML has already been used with success to analyse the safety of medical robot applications [START_REF] Guiochet | Safety analysis of a medical robot for tele-echography[END_REF]. This application showed that this subset of UML (i.e., use-case and sequence diagrams) is well-adapted to model physical humanrobot interaction. The HAZOP method is then adapted and applied to each element of the UML model. HAZOP is also well-adapted to early development stages. It is easily understandable and enables a systematic analysis through the use of guidewords. Finally, we developed a CASE tool that facilitates the use of the method, especially on complex cases.

Although many works have studied the combination of UML and HAZOP on computer systems, none we know of focuses on human-robot interactions. In this paper, we present the HAZOP method, the UML language and their combination in Section 2. In Section 3, we adapt HAZOP attributes for generic interpretations of UML use case and sequence diagrams. This approach is applied, in Section 4, to the analysis of a mobile manipulator robot developed in the PHRIENDS project [START_REF] Phriends | Physical Human-Robot Interaction: Dependability and Safety[END_REF] and to a robotic strolling assistant developed in the MIRAS project [START_REF] Miras | Multimodal Interactive Robot for Assistance in Strolling[END_REF]. Section 6 presents a CASE tool to support our method and Section 7 concludes this paper.

BACKGROUND

The HAZOP method was developed at the beginning of the seventies by ICI (Imperial Chemical Industries). In its original form, the HAZOP method was particularly adapted for the study of thermo-hydraulic systems. The objective of HAZOP analysis is twofold: identify hazards and propose recommendations aimed at reducing the associated risk. The HAZOP method is based on brainstorming done by a group of experts whose collective knowledge has sufficient coverage of the concerned system and application. Through the HA-ZOP method, a system is analyzed by holding a review of the systematic generation of deviations defined by the conjunction of parameters of the system (e.g., pressure, temperature...) and guidewords (e.g., no, more, less...) as presented in Table 1 (generic guideword list from the now obsolete Defence Standard 00-58 [START_REF]HAZOP studies on systems containing programmable electronics[END_REF] and the IEC-61882 standard [START_REF]Hazard and operability studies (HAZOP studies) -Application guide[END_REF]).

The HAZOP method has been adapted to different domains and can be found in many forms with a focus on process, on human error, on procedure, or on software. Modification of the method consists in adapting the list of parameters and the list of guidewords to the specific viewpoint. Even though the HAZOP method is efficient, the results may be questionable when the perimeter of the study is too vast (completeness problem) or when the guidewords are either too numerous or too limited for the analysis to be relevant. Another limitation is that there is no systematic method to adapt the guidewords to the considered domain, so adaptation depends on the expertise of the initiator(s) of the method. Additionally, the HAZOP method needs an appropriate allocation of human resources and suffers from combinatorial explosion when too many deviations are considered or when the practitioners go into too much detail.

Risk analysis is usually performed using a model of the system (e.g., a block diagram). With the advent of objectoriented languages and associated notations (such as UML), many studies have been carried out to determine how those new techniques could be used as input models for risk analysis techniques. UML is a standard general-purpose modeling language that includes a graphical notation enabling the representation of an abstract model of a system [START_REF]OMG unified modeling language (OMG UML), superstructure, v2.1.2. Object Management Group[END_REF]. The UML model of a system is composed of different UML diagrams, each of which is a partial graphical representation of the system that concentrates on a particular viewpoint. Two diagrams are commonly used for description of the system usage: use cases and sequence diagrams. Use cases represent intended use of the system and are linked with the actors that can trigger scenarios of the use case. Each use case is further documented by fields such as pre and post conditions. Each sequence diagram represents one particular scenario of one use case.

Our risk analysis approach is based on a re-interpretation of the HAZOP guidewords presented in table 1 in the context of different UML models. The proposal in [START_REF] Lano | Safety and security analysis of object-oriented models[END_REF], followed by a more systematic study in [START_REF] Hansen | HAZOP analysis of UML-based software architecture descriptions of safety-critical systems[END_REF], considers a guideword interpretation for the deviations of UML elements such as class, association, classifier role, message, etc. A similar approach was followed in [START_REF] Gorski | Development and validation of a HAZOP-based inspection of UML models[END_REF] and [START_REF] Jarzebowicz | Empirical evaluation of reading techniques for UML models inspection[END_REF], which also present a statistical analysis of the usability of this method. The guideword interpretation for the static UML diagrams in those studies aims to inspect the model to identify development faults rather than operational deviations. Nevertheless, for the UML dynamic diagrams (use case, sequence, activity, and statechart diagrams) many guideword interpretations can be used for exploring deviations during operational life. This is the case in studies presented in [START_REF] Johannessen | Hazard analysis in object oriented design of dependable systems[END_REF] and more formally in [START_REF] Allenby | Deriving safety requirements using scenarios[END_REF], which focus on use cases. The latter study led to a method that has been successfully used in [START_REF] Arlow | Safety specification of the active traffic management control system for english motorways[END_REF] and [START_REF] Frantz | Integrating safety and formal analyses using UML and PFS[END_REF]. This work on use cases also inspired a similar approach for security where new interpretations of guidewords have been proposed. Even if this work is more oriented towards malicious behavior of actors [START_REF] Srivatanakul | Security Analysis with Deviational Techniques[END_REF], several interpretations can be applied in safetycritical systems with human-machine interactions. In this paper, we build on the results of those studies, with a focus on use case and sequence diagrams in order to explore deviations during operational life. We also give a particular attention to the integration of HAZOP-like human error analysis techniques as presented in [START_REF] Guiochet | Toward a human-centered UML for risk analysis -application to a medical robot[END_REF]. Indeed human factors methods [START_REF] Stanton | Human Factors Methods: A Practical Guide for Engineering And Design[END_REF] are a major issue in safety-critical systems but their analysis is often uncorrelated from preliminary system modeling activities. On the contrary, a key point of our approach is to consider human factors from the outset, by including them in the preliminary risk analysis.

UML-BASED HAZOP ANALYSIS

In this section, we present our method to analyse risks based on a UML description of human-robot interactions. The description is done using a subset of the UML use case and sequence diagrams. The risk analysis is then performed on this description using an adaptation of the HAZOP method.

UML interaction model

At first, the system goals must be represented using UML use cases. Use cases specify elementary objectives of use of the system (e.g., take an object from user hand). For each use case, a description is provided as well as conditions associated with it. A use case is described by:

-A name providing a unique identifier, for example "Call and autonomous movement of the robot"; The conjunction attribute + guideword facilitates the generation of deviations. We adapted the guidewords of Erreur ! Source du renvoi introuvable. according to the two types of entities. They are presented hereafter in tabular form. Each table associates a list of guidewords for an attribute of one entity. An interpretation of the generic deviation is also provided in order to guide the mental process. Table 3 is the adaptation of the HAZOP guidewords for use cases, and Table 4 for sequence diagrams (which is an extension of the results of Lano et al.

[LAN02]).

Entity = Use Case

Attribute Guideword Interpretation

No/none The condition is not evaluated and can have any value

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

Table 3 -Attributes, guidewords and interpretations for use case entity

-An abstract describing the interaction that occurs in the main scenario of the use case, for example "When called by the user, the robot moves from its current position to a position near the user";

-A series of preconditions that must be satisfied before the use case can be executed, for example "The user called the robot" and "The robot is free from other tasks";

-A series of postconditions that must be satisfied after the use case has been completed successfully, for example "The robot is in the user's vicinity";

-A series of invariants that must be fulfilled throughout the execution of the use case, for example "The robot does not collide with the environment or the user".

UML sequence diagrams are then used to model the interactions between the robotic system and humans. Interaction between objects of the sequence diagram can be represented by messages while actions of one object can be represented using self-messages. We also use annotations to express the types of interaction (physical contact, visual signal, etc.) when the design is sufficiently advanced for that to be known.

For each use case, at least one sequence diagram should be drawn for the nominal scenario. Sequence diagrams should also be drawn for the most pertinent alternative scenarios.

The exceptional scenarios can be ignored as they will be identified and analyzed during the HAZOP analysis.

This UML specification should be done as early as possible in the development process to allow early identification of major risks and consequent adaption of the design to meet the safety requirements of the robotic system. This is possible since the UML specification remains at a very high level of abstraction. The use case diagrams define the purpose of the system and the sequence diagrams of interest describe just the preliminary design of the system.

HAZOP method adaptation

Once the UML interaction model is completed, the HAZOP method is applied by selecting elements of a diagram and applying guidewords to them. In the Defence Standard 00-58 [START_REF]HAZOP studies on systems containing programmable electronics[END_REF], the HAZOP analysis is the systematic identification of every deviation of every attribute of every entity (Figure 1). We define those terms as follows:

-An entity defines what part of the system model is under investigation. In our case it refers to a use case or a sequence diagram.

-An attribute refers to a physical or logical property of an entity:

-For use cases, we choose the fields: (1) preconditions, (2) postconditions, and (3) invariants.

-For sequence diagrams, we identify five attributes for each message: (1) predecessors and successors during the interaction, (2) message timing, (3) send and receive objects, (4) message guard condition and (5) message parameters.

Table 2 is the adaptation of the HAZOP guidewords for use cases, and Table 3 for sequence diagrams. An interpretation of the generic deviation is also provided in order to guide the mental process. These tables were derived from a combination of the different studies presented in section 2, discussions with experts, application of the guidewords to small case studies, models of computation errors, and confrontation with human error models.

Once deviations have been identified, possible consequences and causes are analyzed. To do this, the conditions of execution of the sequence diagram (e.g., environmental conditions or human states) need to be taken into account. The next step is to propose hints regarding possible risk reduction means to prevent the occurrence of deviations or to provide protection against their unwanted effects. One way of preventing the occurrence of deviations is to guarantee that a function or functional block whose failure can give rise to this deviation has a high level of integrity, i.e., it is sufficiently trustworthy to meet the safety objectives. For this, we use the concept of Safety Integrity Levels (SILs) as defined in the ISO/IEC61508 standard [11]. We consider that, for a safety-related function, the SIL is determined only in terms of the severity of the consequences of its failure. Hence, we used a direct mapping between severity levels and SILs. Of course, as presented in the standard, other approaches can be used to calculate a SIL. Such alternatives should be considered for each given project, depending on its safety objectives.

For some functions, it is difficult to meet the assigned SIL requirements. For example, the SIL assigned to a critical software component might require the use of stringent development methods and tools that are not capable of dealing with the complexity of the component. Moreover, some deviations just cannot be treated in this way. For example, the root cause of a human error cannot be mapped to a function to which a SIL can be assigned. For these reasons, other recommendations need to be given to limit the effects of the deviation, such as modifications of the specification, of system usage or of the human-machine interfaces. The final outcome of a UML-HAZOP analysis consists of a list of recommendations and a list of hazards, together with the possible deviations leading to them. This list of hazards may be converted to a list of risks when the probabilities of occurrence of the deviations can be estimated (a risk is a combination of a harm probability and severity [START_REF]Safety aspects -Guidelines for their inclusion in standards[END_REF]). This is possible when the design is sufficiently well advanced to allow the use of other risk analysis methods such as Fault Tree Analysis.

HAZOP analysis table

To assist the HAZOP process, we propose a deviation analysis table with the following columns (cf. example given Table 5 1 ):

1. Element: the UML element on which the deviation is applied.

2. Attribute: the considered attribute.

3. Guideword: the applied guideword.

4. Deviation: the deviation resulting from the combination of the attribute and the guideword.

6. Use Case Effect: effect at the use case level.

7. Real World Effect: possible effect in the real world.

8. Severity: rating of effect of the worst case scenario in the real world. 9. Possible Causes: possible causes of the deviation (software, hardware, human, etc.).

10 Integrity Level Requirements: a preliminary safety integrity level [11] aimed at avoiding the deviation with a sufficient level of confidence (this will lead to the application of specific fault prevention and fault removal techniques [START_REF] Avizienis | Basic Concepts and Taxonomy of Dependable and Secure Computing[END_REF]).

11. New Safety Requirements: if the deviation cannot be avoided, new requirements are specified (e.g., additional fault tolerance techniques, or regulatory constraints).

12. Remarks: explanation of analysis, additional recommendations, etc.

13. Hazard Numbers: real world effects are identified as hazards and assigned a number, helping the users to navigate between results of the study and the HAZOP tables.

CASE STUDIES

This section presents two applications of the method. The first study was performed for the PHRIENDS project [START_REF] Phriends | Physical Human-Robot Interaction: Dependability and Safety[END_REF].

It analyzed the safety of a robotic mobile manipulator. The second study was carried out in the framework of the MI-RAS project [START_REF] Miras | Multimodal Interactive Robot for Assistance in Strolling[END_REF] and analyzed safety of a robotic strolling assistant. For both studies, we rated the severity of deviations (column 8 of the HAZOP analysis table) according to the abbreviated injury scale of [START_REF]The abbreviated injury scale[END_REF]. The first considered system is a wheel-based mobile robot with a manipulator arm (Figure 2). The environment is a workshop and factory with human workers. Collaborative work between a human and the robot is possible (e.g., the robot can give an object to the human). The robot is able to navigate in a dynamic environment where there are other mobile objects (e.g., humans). Identified use cases are: Take an object from a specified location (UC1), Place an object at a specified location (UC2), Go to a location (holding or not holding an object) (UC3), Take an object from the user's hand (UC4), Give an object to the user (UC5), Abort a task (UC6), Guide the robot arm to a location (UC7), Pause and resume a task (UC8), and Physical interaction with the arm (UC9).

Application to a mobile robot manipulator

The five first use cases do not necessarily imply physical contact or even an interaction via an object; they can nonetheless be interrupted by physically stopping the arm of the robot (UC9) in order to switch to one of the use cases UC6, UC7 or UC8. Two more use cases are Program robot (UC10) and Set up (UC11), which, although they can induce major safety problems, have not been considered here since they are quite common use cases in industrial robotics and do not introduce any novelties with respect to human-robot interaction.

For each use case, preconditions, postconditions and invariants were identified, and the nominal scenario was modeled using a sequence diagram. By way of an example, Table 4 shows the description of UC4 Take an object from the user's hand and Figure 3 presents the sequence diagram of the nominal scenario of UC4. Table 5 presents an extract of the study of this sequence diagram. Analysis of the first deviation in this table leads to the requirement of a protocol for communication between user and robot. Analysis of the second deviation in Table 5 leads to the identification of a safer human-robot interaction for passing an object (Remarks column). It is suggested that the robot's behaviour has to be modified.

During this study, 130 elements were analyzed leading to 1694 deviations. However, only 768 deviations (45%) could be interpreted. The sample list of hazards presented in Table 6 is extracted from the full set of HAZOP tables in which 21 hazards were identified. Due to space limitations the table shown does not contain the extra column with the list of sources of each hazard class (this column is contained in our study and in the tool presented in Section 6). This haz-Table 5: Extract of SD4 "Take an object from the user's hand" HAZOP analysis Figure 3: Sequence diagram SD4 giving main scenario of UC4 "Take an object from the user's hand" ard list was checked by robotics experts of the PHRIENDS project (KUKA Roboter GmbH). The analysis led to 18 high-level recommendations, for example:

• R1. The user must be able to stop the robot at any time by touching any part of the robot. Gripper speed is too slow for human/robot synchronization • R4. The robot and the user have to be aware of each other: some device or means should be used to communicate to the user the actual mode of operation of the robot.

• R6. Allow the user to guide not only the robot arm but the mobile base too.

Application to a robotic strolling assistant

The second considered system is a robotic strolling system that helps partially-disabled persons to stand up, stroll and sit down. It is intended to be used in elderly care centers by people suffering from gait and orientation problems. The system consists of a wheeled base and a moving handlebar (cf. The patient stands up with help from the robot Precondition

The patient is sitting down The robot is waiting for the standing up operation Battery charge is sufficient to do this task and to help the patient to sit down again The robot is in front of the patient Postcondition

The patient is standing The robot is in admittance mode Invariant

The patient holds both handles of the robot The robot is in standing up mode Physiological parameters are acceptable

When the risk analysis was carried out, the design of this system was in an earlier stage than for the robot manipulator. Especially UC09, 10 and 11 were not specified at the time the analysis was performed. Table 7 presents the conditions linked to the UC02, Standing up operation. The nominal scenario of this use case is shown in Figure 5.

Out of 993 generated deviations, 297 (30%) were analyzed and 157 led to the identification of 13 main hazards (the other deviations had minor effects). An extract of the hazard list can be found in Table 8. Following the analysis, 26 highlevel recommendations and 17 new safety requirements were issued, for example:

-Filter patient force to avoid oscillation amplification by the robot, -Send regularly a network heartbeat from the robot. Launch alarm on time-out, -Worst-case electrical consumption must be evaluated beforehand.

The application of the UML-HAZOP approach has been compared to a preliminary hazard analysis (PHA [START_REF] Rausand | System Reliability Theory: Models, Statistical Methods and Applications[END_REF]) carried out at the beginning of the project during two workshops with robotic experts. An important result is that our approach identifies all human-robot interaction hazards already identified by the PHA but also new hazards (e.g., a situation where the user is isolated and the system does not have enough power to call the medical staff). Another important result is that all recommendations were approved by robotic experts in the MIRAS project (ISIR2 ). The recommendations were labeled according to the different versions of the prototype (development, validation and final). The second robot prototype will include the corresponding recommendations given by this analysis.

QUALITY OF THE METHOD

To assess the quality of our approach, we analyzed it from four different perspectives: a) integrability, how well does it integrate with the development process? b) usability, is it easy to use? c) validity, are the results complete? d) applicability, can the results be used?

Integrability: the method was designed to be used at the early development stage and can be refined during the design process. Furthermore, it uses common UML for modeling the system and can thus be integrated in a normal development process. In the MIRAS project, all the UML models have been shared and co-designed with the development team.

Usability: Table 9 shows statistics resulting from application of the method to each study. It can be seen that many more deviations were analyzed in the PHRIENDS study than in the MIRAS one. This is mainly because the MIRAS project is still ongoing so its design is less detailed. The combinatorial aspect of the method, which is a common drawback when using HAZOP, was manageable using classical Excel spreadsheets. However, we believe an appropriate tool would be of assistance in this respect.

Another important point defining the usability of the method is that it is easy to understand by non-experts thanks to the UML model and the HAZOP method. Indeed, UML is really common and little expertise is needed to understand the chosen subset of UML. The HAZOP methodology is simple and we have successfully presented it within an hour to our project partners.

Flexibility to design modifications is another important point of the method's usability. When diagrams change, the deviations corresponding to new elements must be created and deviations corresponding to removed elements must be deleted. When physical changes are made on the system (e.g. bumpers around the system to reduce the impact of a collision), hazard numbers enable the corresponding deviations to be found in order to modify the HAZOP tables. Those two points make the method fairly flexible to design changes. However, applying those changes can be timeconsuming when using a standard UML tool and spreadsheet software. Again, an appropriate tool would be useful from this viewpoint.

Validity: as previously mentioned, a Preliminary Hazard Analysis (PHA) had been carried out in the MIRAS project before applying our UML-HAZOP approach. More operational hazards were identified by our method than by the PHA. Note that the common hazards coming from the use of electric machines (electrocution, mechanical projections, etc.) are not covered by our approach, so a complete safety analysis should also integrate methods such as PHA.

Finally, we can draw a positive conclusion about our choice of guidewords. In the first study, all selected guidewords except two ("less than" and "part of" of the predecessor/successor attribute) led to interpreted deviations. In the second study, all selected guidewords except one ("reverse" of the predecessor/successor attribute) led to interpreted deviations (and to recommendations). Neither study used sender/receiver at-tribute guidewords other than "No" because both systems only considered one human and one robot. However, when modelling systems designed to work with several humans or multiple robots, those guidewords be used. Another interesting point is that the two studies were carried out by two different analysts. This explains the use of slightly different guideword depending on the analyst. However, the guidewords lists appear to be complete enough to be used by different analysts with different interpretations.

Applicability: the analyses generate several artifacts: hazard list, HAZOP tables, recommendation list and integrity requirement list. The hazard list enables the identification of major risks of the system. It is linked to a series of safety recommendations to reduce the occurrence or the severity of hazards. In both studies, the hazards and recommendations were accepted by the robotics partners and integrated into the development process. The integrity requirement list leads to significant recommendations from the IEC-61508 standard [11] that are readily exploitable. For certification, the various artifacts can be provided as documention for the measures taken to ensure the safety of the system. Moreover, they are quite concise: we were able to present them to our project partners in a couple of hours.

We therefore conclude positively about the method: it can be easily integrated into a normal development process, it covers the major operational hazards within its scope, and leads to significant recommendations. Although it is usable using standard tools, we decided that a specific tool would be better to handle complex cases and design modifications.

TOOL DESCRIPTION

To ease the analysis of complex systems, we developed a CASE tool to support the method. It helps to manage the combinatorial aspects of the HAZOP method by maintaining consistency between UML models and HAZOP tables and by providing document generation and management features. The tool is built as an Eclipse plugin (www.eclipse.org) using the Graphical Modelling Framework (GMF). In this tool (Figure 6), the analyst can draw UML use-case and sequence diagrams. Using guideword templates, HAZOP tables are automatically generated, ready to be filled out by the analyst.

The analyst can first model the system using use-case diagrams created via a drawing view (view 3 of Figure 6). The toolbox (view 4) enables various elements to be added to the diagram and a property view enables use case conditions to be entered. View 2 shows the diagram view of a sequence diagram. Once the system is modeled, the HAZOP table can be edited using the HazopTable view (view 7). The list of guidewords, the list of columns and the list of severities are editable using the main project view (view 1). Using this template, the list of deviations is automatically generated (view 7). The analyst can then select applicable deviations and fill the corresponding columns. Fast search of specific deviations is available through field 5. Also, when selecting a UML element in a diagram, the corresponding deviations are automatically shown. When filling the table, the recommendation list and corresponding hazards are automatically generated in the project view. The toolbox of the HazopTable view (6) enables deviations to be added (for example, The tool is easy to use because of its simplicity and integration to a common environment. It manages the combinatorial aspects of the HAZOP method by automatic generation of partially filled-out deviations. The method and guideword list can be adapted thanks to HAZOP table templates. Furthermore, the analysis can be exported in CSV to reuse the results outside the tool. However, rich formats like HTML or Excel are not yet available for exportation, which currently limits the integration of our tool with other software. Rich format exportation should permit the generation of the artifacts identified in our case studies: use case list with conditions, sequence diagrams, list of remarks issued during the analysis (incomplete specification, useful relation to existing norms, etc.), list of generated hazards, HAZOP tables, list of recommendations, and list of integrity level requirements. Since we only use a partial subset of UML, the tool cannot be used for the whole modeling process. However, importation and exportation to other software like IBM Rational Software Architect is a planned feature.

CONCLUSION

To tackle safety of robotic systems, appropriate analysis methods are needed. Classic methods suffer from several limitations: unsuited for human-robot interaction, inability to cope with multiple stakeholders and too late implication in the development process. We proposed an adaptation of the HAZOP method to apply it on a subset of the Unified Modeling Language. The method is particularly aimed at modeling physical human-robot interaction early in the development process. The discussions between stakeholders are facilitated through the use of a well-known standard format (UML). Furthermore, since the process is quite systematic, very few analysts are needed once the system is modeled. The combinatorial aspect of the HAZOP method remains manageable since the analysis is restricted to the use case diagram and context sequence diagrams (showing only actors and the system). The developed tool also helps considerably in this respect since it facilitates navigation between generated summary listing and rough analysis contained in the HAZOP tables.

The method has been applied to two systems: a robotic mo-bile manipulator and a robotic strolling assistant. It led to the identification of, respectively, 18 and 26 recommendations to increase the safety of those systems. The recommendations were accepted and taken into account by our partners in both projects. Thus, we believe the method is usable and leads to significant recommendations.

To ease the application of our method, a CASE tool was developed to partially automate the generation of deviations and to manage necessary book-keeping. Further developments are planned to finalize the tool, especially rich format exportations/importations and user interface improvements.

We plan to improve the method further by specializing guidewords for different kinds of message (self-message or interaction) and for different kinds of conditions (precondition, postcondition or invariant). With this specialization, we should reduce the number of proposed deviations, keeping only significant ones.

Figure 4 -

 4 Figure 4 -HAZOP methodology adapted from [MoD Def Stan 00-58:2000]

Figure 1 :

 1 Figure1: HAZOP methodology adapted from[START_REF]HAZOP studies on systems containing programmable electronics[END_REF]

Figure 2 :

 2 Figure 2: Example of a mobile manipulator: "concept omniRob" c at Automatica 2008 exhibition -KUKA Roboter GmbH

Figure 4 )

 4 , and is equipped with several sensors to detect physiological parameters and the posture of the patient. It can also move autonomously. The preliminary design of the robot identified 11 use cases: Strolling (UC01), Standing up operation (UC02), Sitting down operation (UC03), Balance loss handling (UC04), Call and autonomous movement of the robot (UC05), End of use detection and movement to a waiting position (UC06), Positioning the robot by hand (UC07), Alarms handling (UC08), Patient profile programming (UC09), Patient profile learning (UC10), and Robot set-up (UC11).

Figure 4 :

 4 Figure 4: Robuwalker -First prototype

Figure 5 :

 5 Figure 5: Sequence diagram UC02.SD01 giving main scenario of UC02 "Standing up operation"

Figure 6 :

 6 Figure 6: Main view of the CASE Tool to support the UML-HAZOP method

Table 1 :

 1 Generic HAZOP guidewords

	Guideword Interpretation
	No/None	Complete negation of the design intention No part of the
		intention is achieved and nothing else happens
	More	Quantitative increase
	Less	Quantitative decrease
	As Well As	All the design intention is achieved together with additions
	Part of	Only some of the design intention is achieved
	Reverse	The logical opposite of the design intention is achieved
	Other than	Complete substitution, where no part of the original
		intention is achieved but something quite different
		happens
	Early	Something happens earlier than expected relative to clock
		time
	Late	Something happens later than expected relative to clock
		time
	Before	Something happens before it is expected, relating to order
		or sequence
	After	After Something happens after it is expected, relating to
		order or sequence

Table 2 :

 2 Attributes, guidewords and interpretations for use case entity

Table 4 :

 4 Description of UC4 "Take an object from the user's hand"

	Use case name	UC4. Take an object from the user's hand
	Abstract	The user orders the robot to take an object from his hand
		No object in the gripper
	Precondition	Location reachable
		Object can be taken
		Robot base is stopped
	Postcondition	Object in the gripper
		Robot arm is in transportation position
	Invariant	None

Table 6 :

 6

Extract of identified hazards (total number 21) Hazard Hazard description 1 Robot base is moving while it should not 2 Robot arm is moving while it should not 20 Task planning error (fault in the planner or insufficient knowledge of the environment or of the nature of the object) 21

Table 7 :

 7 UC02 "Standing up operation"

	Use case name	UC02. Standing up operation
	Abstract

Table 8 :

 8 Extract of identified hazards (total number[START_REF]Safety aspects -Guidelines for their inclusion in standards[END_REF]

	Hazard	Hazard description	Occurrences
	Number
	1	Incorrect patient position during	7
		robot use
	2	Fall of the patient during robot use	28
	12	Imbalance of the patient caused	33
		by the robot
	13	Patient tiredness	28

Table 9 :

 9 Application of the method -Statistics

	Project	PHRIENDS	MIRAS
	Use Cases	9	11
	Conditions	39	45
	Analyzed deviations	297	317
	Interpreted deviations	179 (60.3%)	134 (42.3%)
	Interpreted deviations with	120 (40.4%)	72 (22.7%)
	recommendation
	Sequence diagrams	9	12
	Messages	91	52
	Analyzed deviations	1397	676
	Interpreted deviations	589 (42.2%)	163 (24.1%)
	Interpreted deviations with	274 (19.6%)	85 (12.6%)
	recommendation
	Totals:
	UML Elements	130	97
	Analyzed deviations	1694	993
	Interpreted deviations	768 (45.33%) 297 (29.9%)
	Interpreted deviations with 394 (23.25%) 157 (15.8%)
	recommendation

For compactness, items 1 and

and items 6 and 7 are grouped into single columns in this table.

Institut des Systèmes Intelligents et de Robotiques, Paris, France

ACKNOWLEDGEMENT

This work was partially supported by the PHRIENDS Specific Targeted Research Project, funded under the 6th Framework Programme of the European Community under Contract IST-045359. It was also partially supported by the MIRAS Research Project, funded under the TecSan (Technologies for Healthcare) programme of the French National Research Agency (ANR).


M Morisson

A Buch

C Szopa

D Glavin

C Freissinet

V Pinnick

W Goetz

M Stambouli

I Belmahdi

P Coll

F Stalport

N Grand

W B Brinckerhoff

F Goesmann

F Raulin

P Mahaffy

SEARCH FOR ORGANIC MATERIAL ON MARS WITH THE THERMOCHEMOLYSIS DERIVATIZATION TECHNIQUE ONBOARD THE MOMA EXPERIMENT

Introduction:

After the SAM experiment onboard the Curiosity rover, the Mars Organic Molecule Analyzer (MOMA) experiment onboard the future ExoMars mission will be the continuation of the search for the organic composition of the Mars surface. MOMA will have the advantage of extracting the sample from as deep as 2 meters below the martian surface to minimize effects of radiation and oxidation on organic materials. To analyse the wide range of organic compounds (volatile and non volatils compounds) pententially present in the martian soil MOMA includes two operational modes: UV laser desorption / ionization ion trap mass spectrometry (LDI-ITMS) and pyrolysis gas chromatography ion trap mass spectrometry (pyr-GC-ITMS). In order to analyse refractory organic compounds and chirality samples which undergo GC-ITMS analysis may be submitted to a derivatization process, consisting in the reaction of the sample components with specific reactants (MTBSTFA [1], DMF-DMA [2] or TMAH [3]). To prove the feasibility of the derivatization within the MOMA conditions we have adapated our laboratory procedure to the space conditions (temperature, time, pressure and size) in order to decrease our detection limits and increase the range of the organic compounds that MOMA will be able to detect. Here, we only discuss the optimization of the thermochemiolysis technique. Derivatization and Thermochemolysis: Usual gas chromatography techniques dedicated to the analysis of non volatile and refractory organic compounds in space include derivatization (MTBSTFA and DMF-DMA) and pyrolysis. Derivatization allows to analyse volatile and non volatile compounds by protecting labil groups at low and intermediate temperatures (75-250°C). Pyrolysis (800-1000°C) allows to analyse insoluble organic material such as macromolecules, but with a major drawback related to the difficulty ofdetermination of the mother molecule because of the high molecular fragmentation. That is why several authors [START_REF] Challinor | pdf 47th Lunar and Planetary Science Conference[END_REF] have introduced thermochemolysis wich allows to reach insoluble matteri in complexe matrix with a limited degradation of the organic material. Combining high temperature and derivatization (methylation), thermochemolysis with tetramethylammonium hydroxide (TMAH) (figure 1) allows to improve the pyrolysis technique wich release polar functional group.

Figure 1 -Thermochemysis reaction with an alcohol.

The methylation prevents secondary degradation of polar compouds and it also allows chromatographic separation of polar compounds with an standard apolar column. Moreover in the case of thermochemolysis, organic material is subjected to lower temperature than with pyrolysis (figure 2). Conclusions: Among the space compatible derivatization techniques, thermochemolysis is the most promising one. It requires one step reaction at medium temperature compared to pyrolysis and allows to reach a wide range of organic compounds which are difficult to reach with pyrolysis or even with MTBSTFA derivatization.

Figure 2 -

 2 Figure 2 -. Overview of the space compatible sample treatment for the in situ GCMS analysis. Optimization of the thermochemolysis parameters for the MOMA experiment: Optimization experiments have been carried out with JSC-1 soil, a martian analogue wich contains high organic concentrations (hydrocarbons, alcohols, amines, amino acids, carboxylic acid ,…). JSC-1 has been first characterized by using classical solvent extraction assisted by ultrasonication. Thermochemolysis has been performed by using a Frontier Lab pyrolyser coupled with a Ther-moFisher GC-MS (Trace-ISQ). Several parameters have been tested: volume of TMAH, impact of solvent (MeOH) using for TMAH dilution, temperature of reaction and time of reaction before the injection. Best results are generally obtained with a TMAH solution 25% w/w in methanol during

Figure 3 -

 3 Figure 3 -. Chromatograms obtained after thermochemolysis of JSC-1 at different temperatures (700°C, 600°C and 500°C). 1 : trimethylamine ; 2 : 1,3,5-trimethyl-1,3,5-triazine ; 3 : N,N'-dibutyl-1,2ethanediamine ; 4 : HMTA ; 5 : pentamethyl-benzene ; 6 : hexamethyl-benzene ; 7 : 6-methoxy-2-(1-buten-3yl)-naphthalene.. TMAH thermochemolysis library: Chromatograms obtained after thermochemolysis may be complexe because of the degradation of organic compouds prior their TMAH derivatization. Moreover methylation can occur in different ways if the molecule contains several labile groups (figure4). That is why we have investigated molecules of astrobiological interest which are difficult to reach with other derivatization techniques. For instance, it is the case of purines and pyrimidines bases. This work will facilitate the interpretation of complexe spectra obtained from unknown samples. It will also help to interpret the SAM results when TMAH experiments start on Mars.

Figure 4 -

 4 Figure 4 -. Chromatograms obtained after thermochemolysis of adenine at 650°C.Conclusions: Among the space compatible derivatization techniques, thermochemolysis is the most promising one. It requires one step reaction at medium temperature compared to pyrolysis and allows to reach a wide range of organic compounds which are difficult to reach with pyrolysis or even with MTBSTFA derivatization.