Robot human supervision requirements should identify who can request, accept, interrupt and resume an operation in each mode, then define how authority changes. A handover needs a request, acceptance conditions, acknowledgment, treatment of previous commands and a response if the exchange fails. For a US industrial robot with local and remote supervision, verify the complete authority transition and physical consequences. A visible operator or remote connection alone does not establish an effective intervention arrangement.
This guide is for systems, controls, operations and verification owners agreeing local and remote robot supervision. Its output is a command-authority and handover table. The buyer's question is whether the engineering record makes it possible to determine who may act now, what confirms the transition and which evidence supports resumption.
What does human supervision mean for a robot?
For this method, supervision means a defined human role in monitoring, authorising or intervening in robot operation. It can include task release, local control, remote assistance or review of an abnormal condition. Those roles need different information and authority. An operator monitoring a display may have no ability to command motion, while a local technician may have control only under specific conditions.
Distinguish the human role from the control mode. A person can observe the same robot in automatic operation, a controlled interruption or recovery, with different permitted actions. Define the commands and decisions available in each state. Do not let the phrase “human in the loop” replace that model.
NIST's robotics measurement programme includes human-robot interaction and tele-operation at different autonomy levels. Its validation emphasis covers components and the integrated system. These research areas support examining both interface usability and actual robot behaviour. They do not specify a universal takeover time or certify that a human arrangement is adequate. (NIST robotics programme, Technical Idea and research thrusts)
The existing requirements-allocation guide assigns hardware, control and AI contributions to a system claim. This article addresses runtime command authority, the exchange between human roles and the evidence for a transition. A person named as a requirement owner is not thereby the active robot controller.
Which authorities and states must be defined?
Define task-request authority, motion-command authority, intervention authority and resumption authority separately where they differ. Also identify who can modify the control or operating arrangement. A supervisor's permission to release a task should not implicitly give permission to bypass a protection or approve a new operating condition.
For each state, record the current authority, allowed commands, preconditions and transitions. Use clear state names based on the actual controller and operating procedure. “Manual” is incomplete unless the project says which interface can act, what limits apply and what the robot does with automatic commands.
Treat protective functions and hazardous-energy controls as separate requirements. OSHA's 1910.147 definition excludes control-circuit devices from energy-isolating devices, so changing to a local or stopped mode does not by itself establish isolation for covered servicing. Assess the actual activity and controls. (OSHA 1910.147(a) and (b))
A control-authority model should make that boundary visible. A local recovery mode may permit a defined operational action, while a servicing task may require a different procedure. The state name cannot decide which legal or safety arrangement applies.
How should a command-authority table describe handover?
Describe the request, granting conditions, acknowledgment, withdrawal and failure response for each relevant transition. State when the prior authority loses its ability to command. If the system supports multiple command sources, define the arbitration explicitly and verify its effective behaviour.
The following fictional, unexecuted example concerns a supervised US manufacturing inspection cell, CEDAR-5. A remote supervisor may release inspection tasks, while a trained local role may request a defined recovery mode. No actual controller, personnel appointment, safety assessment or test exists. The states are teaching labels, not standard-defined modes.
| Proposed state or transition | Active authority and permitted action | Transition conditions and acknowledgment | Evidence and unresolved decision |
|---|---|---|---|
| Automatic task-ready | Task service may request an approved task, controller owns motion execution | The controller reports the accepted task and current configuration | Verify accepted and rejected requests. Task permission must not imply permission to change operating scope |
| Local takeover requested | Local role requests authority, previous motion authority remains explicitly identified | Controller evaluates the required state, inhibits the relevant future command acceptance and reports grant or refusal | Define what happens to active motion and buffered tasks before approving the transition |
| Local recovery active | Only the declared local interface can issue the permitted recovery commands | Local authority begins only after the defined acknowledgment and required conditions | Challenge simultaneous remote commands, queued commands and lost local control information |
| Return to automatic requested | Local role withdraws recovery authority and requests readiness review | Controller clears or dispositions old commands, establishes task and workspace prerequisites, reports readiness | Define whether a separate authorised task release is required. A mode change alone cannot start an old task |
| Supervision connection lost | Connection monitor identifies the defined loss condition | The approved loss-of-supervision response applies to the current mode | Select response and timing from the application assessment, then test loss during each consequential transition |
| Intervention complete | Resumption authority reviews the current task, load and workspace state | New task acceptance follows the approved restart conditions | Verify rejected premature resumption and record the operator-facing reason |
The second row exposes a frequent ambiguity: does a takeover request merely ask for authority, or does it already stop the previous command source? That must be a defined state transition. The answer may differ by design, but both the requester's feedback and the controller's effective command behaviour need evidence.
A table should also identify refusal. If a requested transition cannot be granted, the requester needs an accurate status and the robot needs a defined continuing response. Silence should not be interpreted as successful takeover. Record the reason and whether another action is available under the approved procedure.
What should a handover requirement actually say?
Write separate requirements for requesting authority, granting it, reporting it and enforcing it. For example, a fictional candidate requirement could state: “While local recovery authority is active, the controller shall reject remote motion-command requests through interface IF-R5.” Another could prohibit executing buffered automatic tasks merely because local authority is withdrawn.
These sentences are narrow engineering proposals. They do not define a complete safe handover. The application still needs conditions for granting local control, treatment of active motion and load, protection arrangements, permitted local actions and resumption. Keep those dependencies connected to the candidate requirements.
State the observation point for every criterion. A user-interface indicator showing “local” cannot prove that the controller rejected remote commands. Conversely, a controller log may demonstrate arbitration while leaving the operator unable to understand which authority is active. Verification should address each claim with the relevant evidence.
Use the robotics interface guide to define command identity, endpoint versions, acknowledgments and message meaning. This handover method adds the authority state and prohibited transitions that those messages must implement.
What information does the human need before intervening?
Identify the decision the person is expected to make. They may need current mode, command source, task identity, fault reason, freshness of observations, load state and unresolved restrictions. The information must correspond to the actual robot state, including delay or missing information where that affects the decision.
Separate an operator's ability to issue a command from their ability to judge it. A remote supervisor may lack direct visibility of the workspace. Define what evidence or site confirmation the approved task requires. Do not assume the presence of video establishes adequate perception of every hazard or physical condition.
NASA's product-validation guidance calls for representative operators or users where possible and for accounting for skills, knowledge, training, clothing and tools when humans are involved. These transferable methods support evaluating the actual role and interface. They do not impose NASA flight-crew requirements on a commercial robot. (NASA Systems Engineering Handbook, 5.4.1.2.1, Product Validation Preparation)
For a US factory, evaluate the role under the actual local and remote procedures. Review whether the person can recognise grant, refusal and unavailable information, and whether their permitted action matches the system requirement. A training attendance record alone does not demonstrate the controller's authority enforcement.
Which handover and supervision failures need testing?
Challenge simultaneous command requests, delayed acknowledgments, stale status, connection loss during transition, duplicate requests, requester withdrawal and a controller restart. Also challenge buffered commands and incomplete physical recovery. Select cases from the actual state model and credible failure consequences.
Retain command identity, source, request, effective grant or refusal, acknowledgment, controller state and physical outcome. Use evidence that can associate a particular input with the resulting decision. A screenshot of the final mode cannot reconstruct what happened to a command queued during takeover.
Verify the operator-facing result separately where needed. The person should not receive a grant indication while the controller still accepts conflicting commands. Nor should the interface imply that returning to automatic confirms a workspace condition that no system or authorised person has established.
NASA's verification guidance emphasises the requirement baseline, product configuration, procedure and analysis of discrepancies. Apply that record discipline to the controller, interface and operating procedure revisions examined in the handover evaluation. (NASA, 5.3.1.1 and 5.3.1.2)
What failure should hold the local-to-automatic transition?
In the fictional CEDAR-5 proposal, a remote task request can remain buffered while a local technician resolves an interrupted inspection. The draft return-to-automatic requirement changes the mode and restores the remote connection, but says nothing about the retained task. A planned interface test only checks the displayed mode.
The unowned behaviour is the buffered command after the intervention. The workspace and task may have changed, and neither mode display nor reconnection establishes the prerequisites for executing it. The requirements need a disposition for old commands and a separate resumption or task-release rule.
A proposed review would hold that transition claim, define the prohibited automatic execution and add evidence for queued requests, changed physical state and rejected premature resumption. No failure has been observed and no test has run in this example. A later display check would address only its declared interface claim.
The robotics configuration-evidence guide helps retain the tested combination of controller, local/remote interfaces and procedure. The safety-function traceability guide supports the separate assurance work where authority transitions interact with protective functions.
How can Arc support the handover review?
Arc's programme model connects configured state, authority, requirement and interface records to verification and evidence. Attributable reviews preserve the reviewed context and decision, while controlled changes retain proposed differences before baseline approval.
The team defines the state model, implementation, test criteria and operational authority. Arc can organise the requirements and review history. It does not arbitrate robot commands, monitor operators or determine that a handover arrangement is safe.
Sources and method
Prepared on 2 November 2026 from NIST's robotics measurement programme, NASA's verification and validation guidance, OSHA's hazardous-energy scope and Arc's canonical capability-page source. Definitions, state names and handover requirements are editorial engineering methods. The CEDAR-5 example is fictional and unexecuted. No universal takeover time, operator ratio, safeguarding target or approved operating mode is claimed. This develops roadmap R26's human supervision and command-authority purpose. Arc has a commercial interest in requirements and evidence workflows.
Frequently asked questions
Does human supervision mean the operator always has motion authority?
No. Define whether the role observes, authorises tasks, requests takeover, commands local motion or approves resumption. Different states can give the same person different permissions. Keep task authority, motion authority and safety-related procedures explicit.
What distinguishes a takeover request from a granted handover?
A request asks for a transition. A grant confirms that the defined conditions are met and the authority change is effective. Specify the acknowledgment, prior-command treatment and response to refusal or missing information. Do not let an unacknowledged request imply authority.
Does switching to local control establish lockout/tagout?
A control mode is not proof of hazardous-energy isolation. OSHA's 1910.147 definition excludes control-circuit devices from energy-isolating devices. Assess the actual servicing activity and required energy-control arrangement separately from operational command authority. (1910.147(a) and (b))
Is a mode indicator enough to verify command arbitration?
It can support an interface-display claim. Command arbitration also needs evidence that the controller accepts and rejects the defined sources in each state, including queued and simultaneous requests. Retain the input-to-decision association and resulting behaviour.
What should permit automatic operation after an intervention?
Use the approved resumption conditions and authority. Establish current task, load and workspace state, dispose of old commands and require any separate task release the design specifies. A connection returning or mode changing should not silently satisfy those prerequisites.