Autonomy needs boundaries.
A robot that can make decisions must also understand what it is not allowed to do. Safety is therefore not a single sensor or emergency button. It is a layered system of constraints, monitoring, hardware limits and human authority.
Safety is an architecture.
ARUS treats safety as a system-level engineering discipline. The required architecture depends on the machine, task, environment and deployment. No universal statement can make every robotic operation safe. Safety must be engineered for the actual work.
Autonomy is allowed through layers, not by assumption.
The operator remains part of the system.
Depending on deployment architecture, human authority may include supervised autonomy, manual stop, emergency stop, manual intervention, restricted operating modes, task approval, remote supervision and maintenance control. Autonomy does not remove operational responsibility.
Override
Human command can interrupt autonomous task execution.
Stop
Stop states are separated from normal task pauses.
Supervision
Operating state and uncertainty are exposed to operators.
Intervention
Manual procedures depend on the machine and deployment.
Uncertain state changes the allowed behaviour.
When sensor confidence degrades, communication is lost, obstruction appears, motion becomes inconsistent or system state becomes uncertain, the robot should move toward a defined safe state for that deployment.
The robot operates inside physical envelopes.
Speed zones
Allowed speed depends on area, task, payload and proximity.
Force limits
Force constraints bound contact-rich motion and manipulation.
Restricted regions
Operating maps can define no-go areas and guarded zones.
Collision margins
Motion planning keeps clearance and response distance in view.
Validation moves from model to controlled operation.
Safety validation is deployment-specific. ARUS uses staged checks across simulation, bench work, subsystem testing, integrated testing, controlled pilots and operational rollout.
A safety system must be observable.
Event logs
Actions, stops and state changes are part of diagnostic history.
Telemetry
Robot state, confidence and faults help operators understand operation.
State
Operating state should be explicit across robot, interface and team.
Diagnostics
Fault reporting supports recovery, review and engineering change.
Safety implementation varies by machine type.
AR-H, AR-M and AR-X share the same safety philosophy, but the implementation changes with body architecture, mobility, payload, tooling, operating space and human proximity.
Discuss safety constraints before deployment.
The right safety conversation starts with task scope, environment, people, payload, tooling and recovery states.