Safety in Interactive Systems

1. Safety in Interactive Systems Christopher Power Human Computer Interaction Research Group Department of Computer Science University of York

2. Safety? • Usually in HCIT, we have talked about properties of the interactive system as being facets of usability • However, there are other properties that we often need to consider – safety is one of them • Informally, safety in interactive systems broadly means preventing incidents that can lead to catastrophic loss, either from the human, the machine or the organisation

3. Example case: High Speed Train Derailment • A high speed train crashed in Spain 25 July 2013 • The train derailed at 192 km/h on a curve that was only rated for 80 km/h • 79 people died, hundreds more injured • The following were ruled out: • Mechanical failure in the train • Technical failure in the track • Sabotage • Terrorism • What is left? • The media referred to it as “Human Error”

4. Human error • We often talk about “human error” – but this term is kind of meaningless • Why is it meaningless though? • Because life is messy … there are lots of routes to any given error • Observed phenomena may be caused by many underlying factors, some related to the human, some to the device and some to the environment/context

5. Reason’s “Swiss Cheese” Model of Human Error • John Reason proposed a model in 1990 for understanding where error occurs by categorizing them by the process where they occur. • Proposed that errors could occur in one process be propagated forward in a system. • Forms the basis for the Human Factors Analysis and Classification System (HFACS)

6. Swiss Cheese Model • Each process is a layer of cheese, with holes where errors can slip through:

7. HFACS: Swiss Cheese Model • In most cases safe-guards in other processes catch them and correct them.

8. HFACS: Swiss Cheese Model • However, sometimes the holes in the system line up, and an error makes it all the way to the end with the effects of the error being realised.

9. Unsafe Acts • Unsafe acts are those that are tied to the action cycle involving humans and system interaction. Errors and violations

10. Returning to the train accident … • What went wrong? • The driver was distracted at 192 km/h for 2 minutes by a call on his work phone • It was to inform him that there was a change in the platform he would be coming in on • At 192 km/h that’s a looooong time to be on the phone • By the time he came off the phone, it was too late for him to stop

11. Train Accident Sources of Error • Where were the potential sources of error? No policy on the length of call that one should have while in control of the train – nothing to prevent this from happening again Call came in that was unexpected, but within the regulations Loss of attention due to call Leads to delay in altering speed

12. An easier case … • You are in a restaurant, and you have enjoyed a nice meal. You offer to pay and the server brings you the machine to pay by card. You attempt to pay three times, and you find a message ‘your card has been locked’ • What went wrong?

13. Unsafe Acts • Similar to the interaction cycle discussed in other modules: • Errors deal with the perception, evaluation, integration and executing actions. • Violations deal with goals, intentions and plans

14. HEA and HRA • How is this classification useful to us? • In respect to error, there are two different processes that we can undertake: • Human Error Analysis – trying to capture where errors can happen in the system, either proactively (evaluation prior to incident) or retrospectively • Human Reliability Analysis – trying to capture the probability that a human will have a fault in the system at some point

15. Human Error Analysis Techniques • There are around 40 different techniques that I could point to in the literature • Many of these have little empirical basis and have never been validated • Some have had some work done, but it is debatable how well they work • We’re going to look at different types of error analysis methods over the next couple of hours

16. Error Modes • Most modern techniques use the idea of an “error mode” • Error modes are categories of phenomena that we see when an incident occurs in the world • These phenomena could have many causes – we can track back along the causal chain • Alternatively we can use the phenomena we see (or suspect will happen) and compare it to interface components to see what might happen in the future

17. SHERPA

18. Background • SHERPA stands for “The Systematic Human Error Reduction and Prediction Approach” • Developed by Embreyin the mid-1980s for the nuclear reprocessing industry (but you cannot find the original reference!) • Has more recently been applied with notable success to a number of other domains • (Baber and Stanton 1996, Stanton 1998, Salmon et al.2002, Harris et al. 2005…) • Has its roots in Rasmussen’s “SRK” model (1982)…

19. Skills-Rules-Knowledge • Skill-based actions • Those that require very little conscious control e.g. driving a car on a known route • Rule-based actions • Those which deviate from “normal” but can be dealt with using rules stored in memory or rules which are otherwise e.g. setting the timer on an oven • Knowledge-based actions • The highest level of behaviour, applicable when the user has either run out of rules to apply or did not have any applicable rules in the first place. At that time the user is required to use in-depth problem solving skills and knowledge of the mechanics of the system to proceede.g. pilot response during QF32 incident

20. SHERPA Taxonomy • SHERPA, like many HEI techniques has it’s own cut-down taxonomy, here drawn up taking cues from SRK • Uses prompts are firmly based on operator behaviours as opposed to listing conceivable errors in taxonomic approaches • The taxonomy was “domain specific” (nuclear), but SHERPA has still been shown to work well across other domains (see references) • Rather than have the evaluator consider what psychological level the error has occurred at, the taxonomy simplifies this into the most likely manifestations (modes) for errors to occur

21. SHERPA Taxonomy • The headings for SHERPA’s modes are (expanded next): • Action (doing something like pressing a button) • Retrieval (getting information from a screen or instruction list) • Checking (verifying action) • Selection (choosing one of a number of options) • Information Communication (conversation/radio call etc.)

22. Taxonomy - Action • Action modes: • A1: Operation too long/short • A2: Operation mistimed • A3: Operation in wrong direction • A4: Operation too little/much • A5: Misalign • A6: Right operation on wrong object • A7: Wrong operation on right object • A8: Operation omitted • A9: Operation incomplete • A10: Wrong operation on wrong object

23. Taxonomy - Retrieval & Checking • Retrieval modes are: • R1: Information not obtained • R2: Wrong information obtained • R3: Information retrieval incomplete • Checking modes are: • C1: Check omitted • C2: Check incomplete • C3: Right check on wrong object • C4: Wrong check on right object • C5: Check mistimed • C6: Wrong check on wrong object

24. Taxonomy - Selection & Comms. • Selection modes are: • S1: Selection omitted • S2: Wrong selection made • Information Communication modes are: • I1: Information not communicated • I2: Wrong information communicated • I3: Information communication incomplete

25. SHERPA Methodology • SHERPA begins like many HEI methods, with a Hierarchical Task Analysis (HTA) • Then the ‘credible’ error modes are applied to each of the bottom-level tasks in the HTA • The analyst categorises each task into a behaviour, and then determines if any of the error modes provided are credible • Each credible error is then considered in terms of consequence, error recovery, probability and criticality

26. Step 1 - HTA • Using the example of a Sat-nav

27. Step 2 - Task Classification • Each task at the bottom level of the HTA is classified into a category from the taxonomy Action Action Selection Action Retrieval

28. Step 3 – Error Identification • For the category selected for a given task, the credible error modes are selected and a description of the error provided Selection: “Wrong selection made” – The user makes the wrong selection, clicking “point of interest” or something similar Retrieval “Wrong information obtained” – The user reads the wrong postcode and inputs it

29. Step 4 – Consequence Analysis • For each error, the analyst considers the consequences The user makes the wrong selection, clicking “point of interest” or something similar… This would lead to the wrong menu being displayed which may confuse the user The user reads the wrong postcode and inputs it… Depending on the validity of the entry made the user may plot a course to the wrong destination

30. Step 5 – Recovery Analysis • For each error, the analyst considers the potential for recovery The user makes the wrong selection… There is good recovery potential from this error as the desired option will not be available and back buttons are provided. This may take a few menus before the correct one is selected though The user reads the wrong postcode and inputs it… The recovery potential from this is fair, from the perspective that the sat Nav shows the duration and overview of the route, so depending on how far wrong the postcode is, it may be noticed at that point

31. Steps 6, 7 – Probability & Criticality • Step 6 is an ordinal probability analysis, where L/M/H is assigned to the error based on previous occurrence • This requires experience and/or subject matter expertise • Step 7 is a criticality analysis, which is done in a binary fashion binary (it is either critical or it is not critical)

32. Step 8 – Remedy • Step 8 is a remedy analysis, where error reduction strategies are proposed under the headings; • Equipment, Training, Procedures, Organisational Equipment The use of the term ‘address’ may confuse some people when intending to input a postcode…as postcode is a common entry, perhaps it should not be beneath ‘address’ in the menu system Procedure The user should check the destination/postcode entered for validity. The device design could display the destination more clearly than it does to offer confirmation to the user

33. Output • Output of a full SHERPA analysis (Stanton et al 2005)

34. Output

35. Summary • “Human error” is a misnomer – there are a number of different things that contribute to failures in interactive systems • SHERPA is an alternative to other inspection methods • Claims in the literature point to it being “more easy to learn” and “more easy to apply by novices” – which is attractive • Founded on some of the roots of HF work done in the 1970s but … • … simplifies that work into something that can be applied

36. References • Rasmussen, J. (1982) Human errors, a taxonomy for describing human malfunction in industrial installations. The Journal of Occupational Accidents, 4, 22. • Baber, C. & N. A. Stanton (1996) Human error identification techniques applied to public technology: Predictions compared with observed use. Applied Ergonomics, 27, 119-131. • Stanton, N. 1998. Human Factors in Consumer Products. CRC Press. • Salmon, P., N. Stanton, M. Young, D. Harris, J. Demagalski, A. Marshall, T. Waldman & S. Dekker. 2002. Using Existing HEI Techniques to Predict Pilot Error: A Comparison of SHERPA, HAZOP and HEIST. HCI-02 Proceedings. • Harris, D., N. A. Stanton, A. Marshall, M. S. Young, J. Demagalski & P. Salmon (2005) Using SHERPA to predict design-induced error on the flight deck. Aerospace Science and Technology, 9, 525-532. • Stanton, N., P. Salmon, G. Walker, C. Baber & D. Jenkins. 2005. Human Factors Methods. Ashgate.

37. Action modes: • A1: Operation too long/short • A2: Operation mistimed • A3: Operation in wrong direction • A4: Operation too little/much • A5: Misalign • A6: Right operation on wrong object • A7: Wrong operation on right object • A8: Operation omitted • A9: Operation incomplete • A10: Wrong operation on wrong object • Selection modes are: • S1: Selection omitted • S2: Wrong selection made • Retrieval modes are: • R1: Information not obtained • R2: Wrong information obtained • R3: Information retrieval incomplete • Checking modes are: • C1: Check omitted • C2: Check incomplete • C3: Right check on wrong object • C4: Wrong check on right object • C5: Check mistimed • C6: Wrong check on wrong object • Information Communication modes are: • I1: Information not communicated • I2: Wrong information communicated • I3: Information communication incomplete