A six-step method to map how operators notice, diagnose and recover from robot stops, with a worked example flow and a checklist you can use tomorrow.
Universal Robots puts one sentence in its service documentation that every HMI designer should pin above their desk: "An application which results in daily protective stops is not designed correctly and needs to be modified."
That sentence is aimed at integrators and their programs. I read it as a design brief. On a robot cell a stop is not an edge case. Every cell will stop at some point, and the screens an operator sees in the minute after a stop decide whether the cause gets found or whether someone taps "OK" until the warning goes away.
In my view, too many HMI projects start with the happy path (load job, start, monitor, finish) and leave recovery for last, as a generic modal with an error code. That order is backwards. The happy path is the flow operators repeat calmly. The recovery flow is the one they use under pressure, with a line waiting, sometimes on a shift where nobody from engineering is around. It deserves to be designed first.
This post gives you a method to map that flow, a worked example you can adapt, and a checklist to review it.
Why recovery is the journey that builds or breaks trust
A 2018 human-robot interaction literature review makes the same point. In their review in Frontiers in Psychology, Shanee Honig and Tal Oron-Gilad of Ben-Gurion University note that "more focus has been given to technical failures than interaction failures" and that few studies looked at "communicating failures". They also point out that "how a robot manages failure influences willingness to use the robot again", and that "having to rely on a professional to understand and resolve a robot's faulty behavior is a barrier to acceptance amongst untrained users."
Their model of failure handling has three parts: communicating failures, perception and comprehension of failures, and solving failures. Those three parts map neatly onto screens. Communicate is the alert. Comprehend is the diagnosis view. Solve is the guided fix and the resume. Their review focuses mostly on service and social robots, but the point carries over to cell operators. If one of the three is missing, the operator fills the gap with guesswork or a phone call.
Universal Robots says the same thing from the safety side. Its Preventive Measures page warns that faults "can be hidden from view" by "personnel simply resetting a fault without review of why the fault has happened", and states that "protective stops must never be acknowledged and reset automatically, it must always be a deliberate action by a user to resume after a protective stop." Its protective stop service note goes further: a protective stop warning "SHALL NOT be reset without a review to determine the fault's root cause."
Read those two sources together and you have the brief: make the cause visible, make the review easy, and make resuming a deliberate act. That is a flow, not a dialog.
Step 0: know which kind of stop you are designing for
Not all stops recover the same way, and a single "Error" template flattens differences the operator needs to see. The Universal Robots stop recovery tutorial is a clear public example of how different the paths are. It describes recovery through Dashboard Server commands for external control, but an operator HMI has to take the operator through an equivalent sequence:
Protective stop. "A stop initiated by the robot controller due to the robot state's proximity to a limit." The robot "stops playing program, while retaining power." Recovery is close the safety popup, unlock the protective stop, then play, and the program is started from where it stopped.
Robot emergency stop. The user "manually releases E-stop button", then the sequence adds brake release, and the program restarts from the beginning.
Safety fault or violation. The robot "goes to fault state and powers off robot", which is a different recovery path again.
Other vendors name and sequence these differently, so check your own controller's documentation. The design point holds everywhere: the recovery path depends on the stop type, and the operator should see which path they are on before they touch anything. "Resume from step 14" and "restart from the beginning" are very different promises.
Figure 1. Recovery depends on the stop type. Example paths based on the Universal Robots PolyScope stop recovery tutorial; other controllers differ.
A six-step method to map a recovery flow
This is the method I recommend for mapping recovery on a cell or machine HMI. It works on a whiteboard or in FigJam, and it does not need final UI.
1. Inventory the events. Pull the real list of stops, faults and warnings from controller logs, service tickets and integrator notes. Do not start from the error code table alone. You want frequency next to each event: what actually happens every day, and what happens once a year.
2. Classify each event. For each one, record the stop type, whether power is retained, where the program can resume, and the cause family. Honig and Oron-Gilad's split is a useful first cut: technical failures, "caused either by hardware errors or problems in the robot's software system", and interaction failures, which "arise from uncertainties in the interaction with the environment, other agents, and humans". On a cell, a gripper missing a part and a person stepping into a scanner field need different screens.
3. Define the operator response, or demote it. Alarm management has a rule designers should borrow. IEC 62682, as quoted in an ABB/IChemE webinar by Ian Kemble of ABB (May 2021), defines an alarm as a means of indicating "an equipment malfunction, process deviation, or abnormal condition requiring a timely response", and Kemble advises to "only present alarms that are linked to response and corrective action to resolve the alarm". By that definition, if an event has no defined operator action, it is not an alarm. Log it, show it as a status, but do not interrupt with it.
4. Write the screen sequence. For every event that survives step 3, map the same six stages: Notice, Diagnose, Make safe, Fix, Confirm, Resume. Name the screen for each stage and what it must answer. Figure 2 shows the stages as a reusable skeleton.
5. Write the copy last, against rules. Nielsen Norman Group's error-message guidelines translate well to the shop floor: "Concisely and precisely describe the issue", "Offer constructive advice", "Take a positive tone and don't blame the user", "Preserve the user's input" and "Reduce error-correction effort". On an HMI, preserving input means preserving program position, counters and the job context.
6. Test against rate, not just clarity. EEMUA Publication 191, as summarised by Control Global, treats less than one alarm per 10 minutes as "very likely to be acceptable", and less than ten alarms in the 10 minutes following an upset as "should be manageable, but may be difficult" for the operator. Those numbers come from process control rooms, not robot cells, so treat them as a sanity check rather than a target. If your inventory from step 1 shows a cell interrupting an operator far more often than that, the fix is in the application or the alarm design, not in nicer modals.
Figure 2. The recovery skeleton. Every alarm that needs an operator response gets all six stages. Method by Leon Potgieter; requirement notes from Universal Robots and NN/g sources.
Worked example: a protective stop on a pick-and-place cell
Here is how the six stages play out for one common event. This is an illustrative flow, not a case study. Adapt the screen names to your product.
S1. Stop banner (Notice). A persistent banner at the top of the main view, in the alarm colour of your system, with the stop type in plain words: "Protective stop. Robot holding position, power on." No modal yet. The operator can still see the cell overview underneath, because context helps diagnosis.
S2. Cause card (Diagnose). Tapping the banner opens a card with three blocks: what happened ("Robot stopped near a force limit during place, step 14"), the likely cause family from your inventory (for example payload or TCP settings, contact with a part or fixture, or the program running close to limits; these mirror the causes listed in UR's service note and Preventive Measures page), and how often this has happened today. Frequency is easy to leave out, and it is the part that tells an operator whether this is a one-off or a pattern.
S3. Make safe. A short state check before any action: who is in the cell, whether the guard is open, what the robot is holding. If your safety concept already handles this, the screen confirms it rather than repeating it.
S4. Fix checklist. A short, event-specific checklist: inspect the gripper, check the part seat, check the fixture. Each item has a tick. If the cause is outside operator scope, the card says so and shows who to call, with the event already packaged for them.
S5. Confirm and resume. One deliberate action, labelled with the consequence: "Resume from step 14" or "Restart program from step 1". This mirrors UR's rule that resuming must be "a deliberate action by a user", and it makes the resume point visible before the tap, not after.
S6. Recurrence log. After resume, the event is written to a readable history with the operator's checklist answers. When the same stop appears for the third time in a shift, the banner should say so and offer an escalation, because UR is explicit that daily protective stops mean the application needs changing.
In my view, a generic error modal with an OK button covers only the first of the six stages, Notice. Figure 3 shows the same stop restructured.
Figure 3. Before and after structure for the same protective stop. Low-fidelity schematic, no vendor UI copied.
Pattern: the deliberate resume
Do:
Show the stop type and the power state in words, not just a colour.
Show where the program will resume before the operator confirms.
Keep the cell overview visible behind the alert.
Count repeats and show the count.
Package the event for the person who will be called.
Don't:
Auto-acknowledge or auto-reset protective stops. UR states this "masks fault detection" and that "no one will see the protective stop".
Put a single "OK" button on a stop that can restart a program from the beginning.
Show only a numeric error code. NN/g's guideline is "Use human-readable language".
Blame the operator in the copy.
Raise an alarm for a normal event. The ABB/IChemE webinar's example is that "pump stopped" or "valve closed" should not be presented as alarms.
Figure 4. Map recovery on a wall with the people who clear the stops, before you open Figma.
Checklist: review your recovery flow
Use this on your next HMI review. If you cannot answer yes, you have found your next design task.
Inventory: Do you have a list of real stop and fault events with frequency, not just the code table?
Classification: Is each event tagged with stop type, power state, resume point and cause family?
Response: Does every alarm have a defined operator action? Have events without one been demoted to status or log?
Six stages: Does every remaining alarm have a Notice, Diagnose, Make safe, Fix, Confirm and Resume screen or state?
Plain language: Can an operator tell the stop type and what to do next in under ten seconds without a manual?
Visible resume point: Is "resume from step N" or "restart from the beginning" shown before confirmation?
Deliberate action: Is resuming always a conscious, labelled action, never an automatic reset?
Repeat counter: Does the HMI show how often this stop has happened in the current shift?
Escalation: When the fix is outside operator scope, does the screen say who to call and pass along the context?
Rate check: Have you compared the real interruption rate against EEMUA 191's guidance as a sanity check?
Conclusion
The recovery flow is where your HMI tells the truth about the cell. A cell that stops often and recovers with a tap on "OK" is a cell that hides its problems from the people who could fix them. A cell that stops, explains itself, counts the repeats and asks for a deliberate resume turns every stop into information.
My position: design recovery first, then the happy path. Map it with the operators and technicians who clear stops for a living, not only with the engineers who wrote the program. Your happy path will be simpler for it, because you will already know which states the machine can be in.
Sources
Universal Robots, "Stop recovery", PolyScope tutorials: https://docs.universal-robots.com/tutorials/controlling-robot-externally/stop-recovery.html
Universal Robots, "Preventive Measures" (ignoring protective stops), e-Series service manual SW 5.23: https://www.universal-robots.com/manuals/EN/HTML/SW5_23/Content/prod-serv-man/E-series/serv-man-protective-stop-ignore.htm
Universal Robots, "Protective Stop CB3 Service Note" (2020): https://www.universal-robots.com/articles/ur/robot-care-maintenance/protective-stop-cb3-service-note/
Honig, S. and Oron-Gilad, T. (2018), "Understanding and Resolving Failures in Human-Robot Interaction: Literature Review and Model Development", Frontiers in Psychology 9:861: https://pmc.ncbi.nlm.nih.gov/articles/PMC6013580/
Kemble, I. (ABB), "Alarm Management: A Practical Guide", ABB/IChemE webinar slides, 6 May 2021: https://www.icheme.org/media/16019/icheme-alarm-management-practical-guide-06_05_2021.pdf
Metzger, D., "ASM Alarm Management Guidelines and ISA-18.2: How Do They Stack Up?", Control Global (2009): https://controlglobal.com/protect/safety-instrumented-systems/article/11382017/asm-alarm-management-guidelines-and-isa-182-how-do-they-stack-up
Neusesser, T. and Sunwall, E., "Error-Message Guidelines", Nielsen Norman Group (2023): https://www.nngroup.com/articles/error-message-guidelines/
