Safety, risk and ethics review

A robot that patrols a public beach can hurt people, frighten wildlife, collect images of children and change how parks staff spend their days. A capstone team is not expected to produce a full certified safety case, but it is expected to identify the hazards and ethical questions its project raises, reduce the risks sensibly, obtain the approvals it needs and document all of this clearly. This lesson shows how to run a proportionate safety and ethics review for a capstone: hazard identification and risk assessment, failure modes and effects analysis, quantifying and tracking project risk, planning safe tests, privacy and research ethics, environmental and social impacts, and the review meeting itself. ROB-450 covered the underlying standards and law in depth; here the aim is to apply them at capstone scale.

Hazard identification and risk assessment

ISO 12100, covered in ROB-450 lesson 2, sets out the general method: determine the limits of the machine, identify hazards across its whole life cycle, estimate and evaluate the risk of each, and reduce risks through inherently safe design first, then safeguards, then information for use. For a capstone, a practical approach is a hazard log built in a team workshop. List the robot's life-cycle phases, such as transport, set-up, operation, charging, maintenance, testing and storage, and for each phase walk through the hazard types: mechanical (crushing, pinching, impact, entanglement), electrical (shock, short circuits, battery fire), thermal, noise, radiation (such as lidar lasers), ergonomic (lifting the robot) and hazards from the environment or from unexpected behaviour.

Each hazard is then rated for severity and likelihood. Many capstones use a simple matrix, for example severity from 1 (negligible) to 4 (serious injury) and likelihood from 1 (rare) to 4 (likely), with the product sorted into low, medium and high bands. The team then records controls and the residual risk after controls. Inherently safe design choices are the strongest: Tern's speed limit of 0.8 m/s, its low mass, its rounded bumpers, its arm force limits and its slow final approach reduce severity whatever else fails. Safeguards, such as the safety lidar's protective field and the emergency stops, reduce likelihood. Information, such as warning labels, the status light and an operator guide, comes last.

Note that the battery fire risk remains medium after controls, because its severity cannot be reduced much. The team accepts it with a written charging procedure, rather than pretending the risk has disappeared. Accepting a residual risk explicitly, with a justification and the approval of the advisor and the lab safety officer, is the honest approach.

Failure modes and effects analysis

A hazard log starts from harms; a failure modes and effects analysis (FMEA) starts from components and asks how each could fail, what effect that would have, and how the failure would be detected. Each failure mode is rated for severity (S), occurrence (O) and detection (D), usually on scales of 1 to 10, where a high detection score means the failure is hard to detect. The risk priority number is their product, \( RPN = S \times O \times D \). RPNs rank failure modes for attention, but they should not be used mechanically: a failure with severity 9 or 10 deserves action even if its RPN is modest, which is why many organizations now use action-priority tables, such as those in the 2019 AIAG and VDA FMEA handbook, rather than RPN thresholds alone.

# FMEA: risk priority numbers before and after actions, with a severity override
fmea = [  # component, failure mode, S, O, D, action, (S, O, D) after
    ("safety lidar", "dirty window blinds field", 9, 4, 6, "self-test + window check in start-up", (9, 2, 2)),
    ("wheel encoder", "cable breaks, odometry lost", 5, 3, 4, "watchdog on encoder rate", (5, 3, 2)),
    ("servo", "overheats and stalls", 4, 5, 5, "temperature monitoring, duty limit", (4, 3, 2)),
    ("GNSS", "RTK fix lost near boardwalk", 6, 6, 3, "fall back to lidar localization; slow down", (4, 6, 2)),
    ("serial link", "corrupted command", 7, 2, 5, "CRC + command timeout", (7, 1, 2)),
    ("battery BMS", "fails to cut off over-discharge", 8, 2, 4, "independent low-voltage cut-off", (8, 1, 3)),
    ("status light", "LED fails", 2, 3, 3, "none (accept)", (2, 3, 3)),
]
rows = []
for comp, mode, s, o, d, act, (s2, o2, d2) in fmea:
    rows.append((s * o * d, s2 * o2 * d2, comp, mode, s, act))
for rpn, rpn2, comp, mode, s, act in sorted(rows, reverse=True):
    flag = "  <- severity >= 8, act regardless of RPN" if s >= 8 else ""
    print(f"RPN {rpn:3d} -> {rpn2:3d}  {comp:13s} {mode:32s}{flag}")
print(f"sum of RPN before {sum(r[0] for r in rows)}, after {sum(r[1] for r in rows)}")

RPN 216 ->  36  safety lidar  dirty window blinds field         <- severity >= 8, act regardless of RPN
RPN 108 ->  48  GNSS          RTK fix lost near boardwalk     
RPN 100 ->  24  servo         overheats and stalls            
RPN  70 ->  14  serial link   corrupted command               
RPN  64 ->  24  battery BMS   fails to cut off over-discharge   <- severity >= 8, act regardless of RPN
RPN  60 ->  30  wheel encoder cable breaks, odometry lost     
RPN  18 ->  18  status light  LED fails                       
sum of RPN before 636, after 194

The analysis put the dirty lidar window at the top, which matched field experience: on the second beach day, wind-blown sand coated the window and shortened the scanner's effective range. The action, a start-up self-test that checks the scanner's contamination warning and a step in the operator checklist to wipe the window, reduced both occurrence and detection scores. The battery management failure has a modest RPN but high severity, so the team added an independent low-voltage cut-off. The status light failure was accepted. An FMEA like this, with before-and-after scores and named actions, is strong evidence for the safety section of the final report.

Quantifying and tracking project risk

Safety risks are about harm; project risks, introduced in lesson 5, are about schedule, cost and performance. Project risks can be quantified by their expected value, probability times impact, where impact is expressed in days of delay or in money. Summing expected values gives the risk exposure, which can be compared with the project buffer: if the exposure in days exceeds the remaining buffer, the plan is not credible. Tracking the exposure over time produces a risk burn-down chart, which should fall as risks are retired through mitigation or simply by passing the point where they could occur.

# Project risk exposure (expected days of delay) and burn-down against the buffer
risks = {  # name: (probability, impact in days, week the risk is retired)
    "servo delivery late":        (0.30, 10, 4),
    "detector fails in sun":      (0.40, 8, 6),
    "chassis rework after PDR":   (0.25, 6, 7),
    "grasp below target":         (0.50, 6, 10),
    "integration brown-outs":     (0.35, 4, 10),
    "beach access lost (nests)":  (0.10, 10, 12),
    "member absent 2 weeks":      (0.20, 5, 13),
}
buffer = {w: 10 if w <= 9 else 10 - 2 * (w - 9) for w in range(1, 14)}   # buffer days left (illustrative)
for week in (1, 3, 5, 7, 9, 11, 12):
    exposure = sum(p * d for p, d, retire in risks.values() if retire > week)
    status = "OK" if exposure <= buffer[week] else "EXCEEDS BUFFER"
    print(f"week {week:2d}: exposure {exposure:4.1f} days, buffer {buffer[week]:2d} days  {status}")

week  1: exposure 14.1 days, buffer 10 days  EXCEEDS BUFFER
week  3: exposure 14.1 days, buffer 10 days  EXCEEDS BUFFER
week  5: exposure 11.1 days, buffer 10 days  EXCEEDS BUFFER
week  7: exposure  6.4 days, buffer 10 days  OK
week  9: exposure  6.4 days, buffer 10 days  OK
week 11: exposure  2.0 days, buffer  6 days  OK
week 12: exposure  1.0 days, buffer  4 days  OK

Early in the term the expected delay exceeds the two-week buffer, which is normal; it tells the team that mitigation must start immediately rather than that the plan is doomed. As the servo delivery, detector and chassis risks are retired, exposure falls below the buffer. Expected value is a planning tool, not a prediction: in any single project a risk either happens or does not. But it gives a defensible, quantitative answer to the reviewer's question "How confident are you in your schedule?".

Planning safe tests

Testing a robot is often more dangerous than operating it, because the robot is unproven. Each test session needs a short test safety plan: the test area and how it will be controlled, the people present and their roles, including a dedicated emergency-stop holder, speed and force limits for the session, the abort criteria, personal protective equipment if needed, and what to do if someone is hurt. For field tests in a public place, the plan also covers permission from the land owner, how members of the public will be kept at a distance, signage, weather limits and insurance.

Tern's beach tests were run only at quiet times, inside a temporary area marked with cones and signs, with two team members acting as spotters who could ask visitors to wait, one holding the wireless emergency stop, and the robot limited to 0.5 m/s until the protective stop had been verified on site that day. The parks department issued a written permission for specific dates and areas, and the university's risk management office confirmed that its liability insurance covered student field activities with the partner's agreement. Teams should start these approvals early; in many institutions they take two to four weeks.

Privacy, data and research ethics

Tern's camera records beach visitors, sometimes including children, even though its purpose is to find litter. Good practice follows privacy-by-design principles: collect only what is needed, keep it only as long as needed, protect it, and be transparent. Tern processes images on board and stores only cropped images of detected litter items with their positions; full frames are not saved except during supervised tests, when people in them are blurred before any data leaves the robot. A sign on the robot and at the test area explains what the robot does and who to contact.

In Canada, a municipal partner is usually subject to provincial public-sector privacy law rather than PIPEDA, for example Ontario's Municipal Freedom of Information and Protection of Privacy Act, and universities are subject to their own provincial public-sector privacy laws. If the capstone's data collection, such as interviews with parks staff or observation of visitors, is research involving humans, it requires review by the institution's research ethics board under the Tri-Council Policy Statement: Ethical Conduct for Research Involving Humans (TCPS 2, 2022). Quality assurance, program evaluation and course-based activities that are not research may be exempt, but the research ethics board makes that determination. Allow several weeks for review.

ROB-430 lesson 8 covered the design of human-robot interaction studies; for the capstone, the practical rules are to ask early, to use the institution's consent templates, never to collect identifiable data without approval, and to store data on institution-approved systems rather than personal accounts.

Environmental and social impacts

Engineering codes of ethics ask engineers to consider the wider effects of their work. For Tern, environmental impacts include disturbance of wildlife, removal of natural material such as seaweed and driftwood that supports beach ecosystems, battery manufacturing and disposal, and the robot itself becoming litter if abandoned. The team's design leaves wrack in place, limits patrols to areas and seasons approved by the parks department, and includes an end-of-life plan for the battery.

The piping plover is listed as endangered under Canada's Species at Risk Act, and migratory birds and their nests are protected under the Migratory Birds Convention Act, 1994, so any robot operating near nesting habitat must be planned with the land manager and, where needed, wildlife authorities.

Social impacts matter too. Parks staff might reasonably worry that a litter robot is a step toward replacing them. Team Tern addressed this openly with the partner: the project's aim was to redirect staff time from repetitive litter picking toward work such as maintenance, visitor education and habitat protection, and staff were involved in testing and design decisions. ROB-450 lesson 11 discussed automation and the future of work in depth; a capstone report should acknowledge these questions rather than ignore them. Public acceptance is also a practical concern: a robot that frightens visitors or seems to film them covertly will not be welcome, however well it works.

The safety and ethics review

Many programs require a safety and ethics review before field testing, often combined with the CDR. The team presents the hazard log, the FMEA, the safety functions and their verification plan, the test safety plans, the approvals obtained or pending, the data management and privacy plan, and the environmental and social considerations. Reviewers typically include the advisor, a lab safety officer and sometimes an ethics representative. The outcome is approval, approval with conditions, or a requirement to revise. Tern's review approved field testing on condition that the protective stop be verified on site at the start of each field day and that the full-frame recording mode be disabled except during supervised tests, both of which the team added to its procedures.