Three Standards, One Body: How Powered Industrial Exoskeletons Expose the Limits of Requirements Management
The System That Shouldn’t Be Possible
A powered industrial exoskeleton is a machine that wears a human being. That single sentence contains a requirements engineering contradiction that has no clean resolution — only managed trade-offs.
Sarcos Robotics, with its Guardian XO full-body exoskeleton, is one of the few companies to take this problem to industrial deployment. The Guardian XO augments a worker’s strength without substituting for their judgment, allowing lift capacities of 90 kg with reported user fatigue reduction. The engineering behind that capability is genuinely impressive. But from a systems engineering standpoint, the more interesting story is how a program like this manages requirements when three distinct regulatory and standards regimes are simultaneously binding — and when those regimes were each designed for a different class of system entirely.
This is not a product review. It is an analysis of the requirements management challenge that any powered exoskeleton for industrial use creates, using Sarcos’ program as the clearest public example of that challenge at production scale.
The Three Regimes
Before examining the conflicts, it’s worth being precise about what each regime demands.
ISO 13849: Machinery Safety
ISO 13849 governs the safety of machinery control systems. It provides a framework for Performance Level (PL) determination — from PLa (lowest) through PLe (highest) — based on severity of potential harm, frequency of exposure, and the possibility of avoidance. A powered exoskeleton that can exert 90 kg of force on a human body is, under this framework, a machine capable of causing serious injury or death. That places relevant safety functions at PL d or PL e, requiring redundant, monitored control architectures with strict diagnostic coverage and mean time to dangerous failure (MTTFd) specifications.
The standard was designed for fixed machinery — presses, robots, conveyor systems. It is being applied to wearable systems through interpretation and extension, not direct specification. That gap is itself a requirements management problem.
Wearable Ergonomics Standards
The human factors and ergonomics (HF/E) requirements for powered wearables draw from ISO 9241 (ergonomics of human-system interaction), EN 547 (human body measurements for machinery design), and increasingly from emerging standards like ISO/TR 23478, which addresses industrial exoskeletons directly but remains technically limited. NIOSH guidelines and OSHA general duty clause obligations layer on top.
These standards share a common demand: the system must not create new injury pathways while mitigating existing ones. For a powered exoskeleton, this means managing interface pressure, joint alignment under load, donning/doffing time, thermal load on the user, and cumulative exposure over shifts. The key parameters are biological and probabilistic — skin pressure tolerance varies by individual, joint kinematics under external loading are not fully standardized, and fatigue accumulation is a function of task variety, not just peak load.
Real-Time Control System Requirements
The software that makes a powered exoskeleton functional must meet timing, latency, and response requirements that are independent of either safety or ergonomics standards but interlock with both. Sensor fusion from inertial measurement units, joint encoders, force-torque sensors, and electromyography (EMG) inputs must be processed within control loop cycles typically in the 1–10 ms range. The control system must maintain stability across the full range of user motion, posture, and external loading — including unanticipated conditions.
These requirements are specified through a combination of DO-178C-style software development rigor (adapted for industrial rather than airborne contexts), IEC 62061 for safety-related software, and internal performance specifications. The timing budgets are hard constraints, not targets.
Where the Conflicts Live
Each standard, taken alone, is manageable. The systems engineering challenge for a program like Guardian XO is that every significant design decision simultaneously touches all three regimes — and the regimes were not designed to talk to each other.
Conflict 1: Emergency Stop vs. User Protection
ISO 13849 requires that safety functions, including emergency stop, be implementable and effective. For a fixed machine, an e-stop means removing power or applying braking. For a powered exoskeleton worn by a human being, an abrupt power removal at the wrong moment — mid-lift, mid-stride, under load — can itself cause the injury the e-stop is meant to prevent. The human factors regime demands that any power-down sequence be controlled, gradual, and posture-aware. The control system requirement is that this controlled power-down must execute within a timing budget that guarantees stability throughout.
The requirement that satisfies ISO 13849 (“e-stop shall remove drive power within X ms”) is in direct tension with the requirement that satisfies ISO 9241 (“system shall support safe postural transition on power removal”). Resolving this requires a safety function architecture that is more sophisticated than the standard contemplates — and the resolution must be captured as a requirement, traced to both parent standards, and verified against both.
Conflict 2: Torque Limits and Ergonomic Load
Setting joint torque limits is simultaneously a safety decision (ISO 13849 hazard reduction), an ergonomic decision (preventing interface force accumulation on the user’s body), and a control system parameter (actuator command saturation). Tighten the torque limit to reduce injury risk from mechanical failure, and you may increase the compensatory loading on the user’s musculoskeletal system because the exoskeleton isn’t doing enough. Raise it to offload the user effectively, and you increase the consequence severity of a control fault.
This is not a conflict that can be resolved by picking one standard and deprioritizing the others. Every torque limit value is a multi-domain engineering decision with traceability obligations in three directions.
Conflict 3: Sensing Latency and Safety Response Time
The safety architecture requires that hazardous conditions be detected and responded to within a defined time budget derived from the ISO 13849 risk assessment. The control system’s sensing and fusion pipeline consumes a portion of that budget just to establish what the system state is. EMG sensing — which can provide early intent detection and improve the ergonomic quality of motion assistance — adds latency and computational load. Adding it improves the ergonomics requirement satisfaction; it may compromise the safety response time budget.
A requirement that says “system shall detect user intent via EMG and initiate assistance within 50 ms” is in tension with a requirement that says “system shall detect control fault and initiate safe state within 20 ms.” Both requirements are legitimate. Their interaction is a systems engineering problem, not a single-domain optimization.
Why Document-Based Requirements Management Fails Here
Traditional requirements management practice — whether implemented in IBM DOORS, a Word document, or a spreadsheet-based RTM — treats requirements as rows in a table. Each requirement has an identifier, a source, a verification method, and a status. Traceability is expressed as links between rows.
This model works adequately for single-domain systems where requirements derive from a coherent standard and design decisions affect a contained scope. It begins to degrade when requirements from different domains interact. It breaks entirely when a single design parameter — like a joint torque limit — must simultaneously satisfy requirements sourced from ISO 13849, an HF/E specification, and a real-time software timing budget, and when changing that parameter for any reason requires a multi-domain impact analysis.
The specific failure modes in document-based tools:
Siloed traceability. Most programs manage safety requirements, software requirements, and human factors requirements in separate documents or separate DOORS modules. When a design decision affects all three, the cross-domain impact is invisible unless someone explicitly performs and documents a manual review. In practice, that review happens at major milestones, not at the moment of the design change.
Static change impact. When a requirement changes — say, a torque limit is revised based on field data from a pilot deployment — the engineer making the change in one module must manually identify and update all downstream requirements and verification evidence in other modules. Miss one link, and you have a gap that may not surface until a certification audit or a field incident.
Verification method mismatch. ISO 13849 safety functions are verified through analysis, testing, and calculation of PL. HF/E requirements are verified through human subject testing, biomechanical simulation, and field observation. Control system timing requirements are verified through software analysis and hardware-in-the-loop testing. Capturing all three verification methods in a single RTM and maintaining coherence across them requires discipline that document tools don’t enforce.
What Better Practice Looks Like
The requirements management approach that this class of system actually demands treats requirements as nodes in a graph, not rows in a table. Each requirement carries its source standard, its domain, its current status, and its relationships — to parent requirements, to sibling requirements from other domains that it interacts with, to design decisions, and to verification evidence.
When a parameter changes, the graph makes the impact visible. A torque limit revision triggers visible alerts across connected nodes in the safety domain, the ergonomics domain, and the software domain simultaneously. The engineer doesn’t have to remember to check; the model surfaces it.
This is the architectural principle behind modern AI-native requirements tools designed for hardware engineering. Flow Engineering, for example, structures requirements as a connected model rather than a document hierarchy, which means cross-domain traceability is a property of the model rather than a discipline imposed on top of it. For a program managing simultaneous ISO 13849, HF/E, and real-time control requirements, that structural difference matters operationally. When the model can surface “this torque limit appears in three requirement clusters with conflicting optimization directions,” the conversation that follows is more productive than discovering the conflict in a design review.
The point isn’t that any single tool solves the problem. The point is that the problem requires a tool architecture that can represent multi-domain requirement interactions as first-class objects — not as manual cross-references between siloed documents.
The Verification Challenge
Requirements management for a system like Guardian XO doesn’t end at the design phase. Verification is itself a multi-domain, multi-method problem.
For ISO 13849 compliance, verification means calculating PL for each safety function, demonstrating diagnostic coverage, documenting MTTFd for hardware components, and producing the safety-related software development evidence required by IEC 62061. This is analysis and documentation work.
For HF/E requirements, verification means human subjects research, biomechanical measurement, pressure mapping at user interfaces, and longitudinal observation of users across shift durations. This is experimental work with statistical uncertainty.
For real-time control requirements, verification means software timing analysis, hardware-in-the-loop simulation, and worst-case execution time (WCET) analysis. This is computational work.
Each verification method produces a different artifact type. A requirements management system that can only capture “verified / not verified” status is insufficient. The system needs to capture what was tested, under what conditions, with what result, and how that result maps to the requirement’s acceptance criteria — across all three methods, for thousands of requirements.
This is where the gap between legacy requirements tools and modern practice is most operationally significant. Programs that can’t manage verification evidence at this level of fidelity accumulate audit risk that typically surfaces during certification, when the cost of gaps is highest.
Honest Assessment
Sarcos’ program, and programs like it, represent one of the genuinely hard problems in industrial systems engineering. The regulatory environment is fragmented — standards designed for fixed machinery, standards designed for consumer ergonomics, and software safety standards designed for aerospace and automotive are being applied together to a class of system that none of them fully anticipated. The conflicts between their demands are not resolvable through compliance procedure; they require engineering judgment and explicit, documented trade-off decisions.
The requirements management infrastructure that most programs in this space use was not designed for this level of complexity. Programs relying on document-based RTMs and siloed DOORS modules are managing multi-domain requirement interactions through manual discipline rather than tool-enforced visibility. That approach works until it doesn’t — and in a domain where a control fault can injure the person the system is supposed to protect, “until it doesn’t” is not an acceptable reliability posture.
The industry is moving toward graph-based, AI-assisted requirements environments. The programs that arrive at that infrastructure early will spend less time in certification remediation and more time on the engineering that actually matters: making systems that work safely on real human bodies, in real industrial environments, under conditions no standard fully anticipated.