A robot’s real architecture appears when something it depends on is missing.
The network drops. A cloud service is slow. A fleet manager is unreachable. A map server cannot be contacted. Remote support is busy. A building integration is offline. A tablet battery dies. A software update is incomplete. The robot may still have motors, sensors, brakes, local compute, and a task in progress, but the surrounding support has thinned. What happens next is not a side case. It is part of the product.
Robot Compute and Connectivity describes where robot decisions run. Offline and degraded modes ask what the robot is allowed to do when that architecture is partially unavailable. The answer should be designed before the outage, not improvised while the machine is blocking a route.
Offline Does Not Mean Powerless
Offline is often used as if it means helpless. Some robots truly cannot do much without a network. Others can continue local navigation, finish a short motion, preserve logs, reject new jobs, return to a dock, or wait in a safe pull-off. The difference depends on which functions are onboard, which are remote, and which permissions require live confirmation.
A useful degraded mode begins with a precise question: what local evidence does the robot still have? It may know its pose, battery state, current load, last assigned task, local map, nearby obstacles, and safety state. It may not know whether a downstream station changed, whether a new priority job arrived, or whether a building door is available. Acting as if nothing changed is risky. Acting as if everything is impossible may be unnecessarily disruptive.
Robot Operational Design Domains applies because degraded operation can be a smaller domain inside the normal one. The robot may be validated to continue along a short known route while offline, but not accept new destinations. It may be allowed to stop safely and preserve a load, but not enter an elevator or manipulate an uncertain object.
The Safest State May Still Need Design
“Stop safely” sounds simple until the robot has to choose where and how. Stopping in a doorway, aisle intersection, elevator threshold, or handoff point may be safe for the robot but disruptive or risky for people. A mobile robot may need a pull-off strategy. A robot arm may need to retract, hold position, lower a payload, or keep a guarded state until a trained person arrives.
The right degraded state depends on the task. A robot carrying a sealed tote can often park and wait. A robot holding a fragile object may need to place it down before stopping if that action is locally safe and validated. A robot interacting with a door, lift, or cart may need a conservative release path. A robot with low battery may need to choose between staying put and reaching a dock.
Robot Failure Recovery covers what happens after trouble appears. Degraded-mode design decides which fallback states are available before recovery starts. A robot that has no good place to wait will create pressure for unsafe manual rescue.
Queued Work Can Become Stale Work
When connectivity returns, the robot may have queued jobs, partial completions, old commands, and stale assumptions. A job that was safe ten minutes ago may no longer be safe. A station may have filled. A person may have moved the tote manually. A route may have been blocked. A supervisor may have cancelled the task through another system.
Resuming blindly can be worse than stopping. The robot should reconcile state before acting. It should know which jobs require confirmation, which can be abandoned, which must be reported as incomplete, and which need a new start-state check. The surrounding system should not assume that offline time is invisible.
Robot Systems Integration matters here because job state lives across several systems. The robot may have one version of the truth, the fleet manager another, and the operations system another. Recovery should bring those records together rather than letting the robot complete a task that the site no longer expects.
Permissions Should Tighten, Not Loosen
Degraded states are tempting moments for shortcuts. A technician wants to move the robot. A floor worker wants the aisle cleared. A remote tool is unavailable. A password is shared. A service port is opened. The pressure is understandable, but degraded operation is exactly when permissions should become clearer.
Robot Security and Access Control makes this point at the security level. Degraded mode should have its own authority model. A local pause should remain easy. A recovery motion may require someone trained and physically present. A reset after a safety event may require inspection. A robot that cannot verify its software or map should not quietly resume normal work because someone found a workaround.
Permission design should also protect logs. If a robot is offline after an incident, preserving evidence may matter more than returning to work quickly. A degraded-mode tool that clears state without recording why can turn a diagnosable event into a mystery.
Logs Must Survive Thin Support
Robots should preserve enough record during degraded operation to explain what happened later. That record may include the last known job, map version, pose, battery state, sensor health, network state, operator actions, remote session attempts, safety events, and local recovery steps. If the network is unavailable, the robot may need local storage and a later sync plan.
Robot Observability and Field Logs is especially important because outages distort memory. People remember the visible stop, not the sequence before it. The robot may have lost fleet contact after a blocked route, after a battery warning, or during a software update. Those are different stories with different fixes.
The log should also record what the robot chose not to do. A refusal to accept new jobs, a decision to park, or a decision to hold a load may look like inactivity from the outside. In degraded mode, refusal can be the correct behavior. The record should make that clear.
Local Interfaces Need To Work Under Stress
When support is thin, the local interface becomes important. It should show the robot’s state plainly enough for the people who are allowed to act. Is the robot safe to approach? Is it carrying a load? Is it waiting for network recovery? Is it asking for a trained technician? Is it preserving logs? Can it be sent to a dock? Can it be moved manually?
This is not an argument for exposing every diagnostic setting on the floor. It is an argument for usable local truth. A worker should not need to guess whether a stopped robot is paused, faulted, disconnected, or awaiting remote support. Robot Status Signals and Floor Cues handles the immediate visible layer. The local interface can carry the next level of detail.
The interface should avoid false certainty. If the robot cannot confirm fleet state, it should say so. If a command will be held until reconnection, that should be visible. If manual movement will end the task record, the person should know before acting.
Degraded Mode Should Be Tested
Outages are often treated as rare, but the behavior should still be tested. A pilot should ask what happens when the network drops mid-route, when remote support is unavailable, when the dock is blocked while the robot is low on battery, when the fleet manager restarts, and when a job is cancelled while the robot is offline. The test does not need to be dramatic. It needs to reveal the robot’s boundary.
Robot Task Design and Acceptance Tests gives the structure. Degraded-mode tests should include start condition, expected fallback, allowed actions, human authority, logging, and recovery after services return. If the robot has never been asked to handle these cases in a controlled setting, the site will discover them during real pressure.
Testing can also show where the site needs physical changes. A pull-off zone may be missing. A dock may be too far for low-battery recovery. A local responder may not know the procedure. A building integration may fail closed in a way the robot cannot interpret. These are deployment findings, not just software bugs.
Dependability Includes Refusal
A dependable robot is not one that keeps working through every missing dependency. It is one that degrades predictably. It knows which functions remain local, which tasks require fresh confirmation, which states are safe to hold, which permissions apply, and which records must be preserved. It does less when less is known.
That restraint can be frustrating in the moment. People may want the robot to finish the job. But a robot that guesses during thin support can turn a network issue into a safety issue, data issue, or workflow issue. A robot that parks clearly, explains its state, preserves evidence, and resumes only after reconciliation is easier to trust.
Offline and degraded modes are not edge decorations around normal operation. They are the proof that the deployment understands its own dependencies. When support thins, the machine should become more conservative, more legible, and more careful with the truth.
