Use case: behavior validation and deployment scaling for humanoids and mobile manipulators — when the near-term problem is operational risk, not finishing a certification binder.
Humanoid programs rarely stall because someone forgot a clause number. They stall because a tote pick fails differently on every site, tip-over risk shows up only under load, and the “supervisor watches every cycle” mitigation doesn’t survive first contact with a real shift.
Teams building free-moving manipulators for warehouses, homes, and jobsites need a loop that answers:
- What fails on this task, in this environment, under this supervision model?
- What do we change — site prep, robot policy, or human response?
- What evidence proves the mitigation before we scale the next cell — sim, SiL, or runtime?
Saphira’s stack for that loop is Task FMEA + virtual testing + software-in-the-loop (SiL) — the same pattern we use with humanoid and construction-robot customers when certification is later, but safe scale-up is now.
The gap classical machinery RA leaves open
ISO 12100 / ISO 13849-style risk assessments remain essential when you are freezing a safety PLC, stop categories, and PL targets (see our Raise Robotics case study). They are the wrong primary artifact when the customer’s next ask is:
- “Will the robot drop totes when lighting changes?”
- “What happens if the aisle is blocked mid-carry?”
- “Can we brief operators on the three things that matter before a shift?”
Those are operational failures at the task interface. They need a living analysis per task and site — not a one-time PL e worksheet for the whole machine.
Use case 1 — Living Task FMEA as the deployment spine
Task FMEA captures system context (robot type, environment, supervision model, downtime policy), decomposes a task into steps, and generates failure modes with causes, worst-case effects, and mitigations split into three operator-actionable buckets:
| Bucket | Examples |
|---|---|
| Site prep | Painted drop zones, aisle clear markings, lighting / label orientation |
| Robot orchestration | Confidence thresholds, replan / reroute, force envelopes, safe-stop posture |
| Supervisor response | Timed alerts, spot-checks on SKU changeover, e-stop on tip cascade |
Statuses move from not started → in progress → validated as evidence lands. The artifact is meant to be briefable: the same rows that drive engineering also feed a pre-operation summary when demos multiply across sites.
This is the spine we use when humanoid teams are depalletizing, sorting debris, or running mixed-traffic carry — and when the top pilot risks are tip-over and property damage, not abstract injury categories on a cert form.
Use case 2 — Virtual testing as mitigation evidence
Simulation is useful only when it answers a named failure mode. The pattern:
- Freeze a Task FMEA row (e.g. balance loss while carrying / wrong tote selected).
- Define the virtual test that would falsify or support the mitigation — domain-randomized lighting, cluttered aisles, uneven CoM, pedestrian intrusion.
- Attach the run (or campaign summary) as evidence on that row — with provenance: stack version, scenario ID, seed, pass/fail against the threshold.
Platforms such as NVIDIA Isaac Sim fit naturally here for perception and manipulation edge cases; the point is not “we ran sim,” it is “this mitigation for this failure was exercised under these conditions.”
For a deeper view of connecting sim campaigns to living safety arguments, see Living Safety Evidence: Connecting Simulation to Continuous Compliance.
Use case 3 — Software-in-the-loop (SiL) for control and recovery policy
Hardware-in-the-loop is expensive to schedule; many recovery policies can be stressed earlier in SiL:
- Planner stuck / timeout → move to safe idle or charge (not wait forever in the aisle)
- Drop detect → controlled place-down vs. unsafe recovery motion
- Mode or supervision assumptions → alert thresholds when only a nearby worker is available
SiL results attach to the same Task FMEA rows as virtual tests and runtime logs. When a control policy changes, you re-run the SiL suite for the affected steps instead of rebuilding a spreadsheet from scratch.
Use case 4 — Humanoid programs that need both tracks
Mature humanoid programs usually need two parallel tracks:
| Track | When it leads | Primary artifacts |
|---|---|---|
| Certification / machinery safety | Freezing safety PLC, sensing, stop architecture, NRTL path | ISO 12100/13849 RA, SRS, safety functions, lab roadmap (Raise, RobCo) |
| Deployment / behavior validation | Pilots, site variants, operator briefings, sim-backed mitigations | Task FMEA, virtual tests, SiL, runtime evidence (1X-style readiness) |
Saphira keeps both in one platform so a tip-over hazard in the RA and a tip-over failure mode in the Task FMEA do not become two disconnected stories — and so investor-facing maturity and operator-facing briefings share the same underlying graph.
What “good” looks like in practice
A humanoid or mobile-manipulator team running this use case typically has:
- One Task FMEA per deployment-critical task (pick-and-place, debris sort, home assist, etc.) with site-specific notes
- Mitigations owned by role — facilities, autonomy, and ops — not a single “safety person owns everything” backlog
- Evidence hooks on high AP rows: Isaac / other virtual campaigns, SiL suites, and eventually runtime metrics (e.g. peak end-effector speed never exceeded over N hours)
- A briefing view that can be regenerated when the next site or shift profile changes
Certification planning can still sit on the roadmap. Deployment risk planning moves to the start of every new task.
Who this is for
- Humanoid and mobile-manipulator teams whose next gate is a customer pilot or demo, not an NRTL stamp
- Groups investing in virtual testing and SiL who need those runs to land on named failures, not a slide deck of “edge cases”
- Ops / applications engineers who need per-site risk that operators can absorb before a shift
Talk to us about wiring Task FMEA to your sim and SiL stack: contact@saphira.ai or saphira.ai.
