The external operating system

At 02:13, a mobile manipulator stops outside a lift. Its battery is healthy, localization confidence is high, and the route planner has a valid path to the next job. The lift gateway has restarted after a software update. The robot can see the closed doors, yet it cannot prove that the cabin is reserved, empty, or going to the requested floor. Nothing inside the machine has failed. Production still stops.

The incident exposes a central truth of Physical AI: autonomy is a property of the complete operating environment. A robot may carry perception, compute and actuation, while its useful capacity depends on energy access, radio coverage, maps, traffic rules, workcell handshakes, doors, lifts, tools, maintenance processes and digital services. These surrounding systems collectively behave like an external operating system. They provide resources, permissions, shared state and recovery mechanisms that no individual machine can create alone.

The distinction matters economically. A laboratory demonstration optimizes the robot and arranges the world around it. An operational fleet must survive people, pallets, cleaning cycles, fire doors, wireless interference, depleted chargers, software releases and changing production priorities. Every dependency adds capability and creates a failure path. The engineering objective is a deliberately designed boundary between mobile autonomy and environmental support.

Modest adaptations often create disproportionate value. A machine-readable lift interface removes uncertain button manipulation. A precisely located docking target reduces charging retries. A standard staging zone prevents a vehicle from blocking an aisle while waiting for work. Fiducials at perceptually ambiguous transitions restore localization confidence. These measures preserve flexibility because they support classes of machines and workflows instead of scripting one robot through one fixed route.

Figure 1 frames this dependency as five linked infrastructure layers.

Five infrastructure layers determine whether robot intelligence becomes dependable capacity:

• Physical affordances: traversable surfaces, clearances, doors, lifts, docks, workstations and human-visible operating cues.
• Energy services: charging, battery exchange, thermal conditioning, isolation, scheduling and recovery from incomplete energy transfer.
• Communication: local wireless and wired access, edge services, time, identity and bounded behavior during service loss.
• Coordination: maps, task allocation, traffic management, resource reservation and interfaces to production or warehouse systems.
• Governance and care: commissioning, updates, evidence, maintenance, cybersecurity, data ownership and lifecycle accountability.

Each layer has a different owner and refresh cycle. Facilities may last decades, industrial control systems years, robot software months and learned models weeks. Productive deployment requires stable contracts across those timescales.

The building becomes part of the machine

A humanoid can climb a step, open a door and press a button. Those capabilities are valuable when the environment is genuinely unstructured. Requiring them at every repeated transition consumes time, energy and reliability margin. The economically stronger design reserves general physical intelligence for variable work and uses simple infrastructure where repetition makes certainty valuable.

The physical contract begins with geometry. Route width must include the robot envelope, carried load, localization uncertainty, braking behavior and the movement of nearby people. Floor transitions affect traction and localization. Reflective glass, repetitive corridors and changing illumination can degrade perception. Thresholds and drainage channels can excite a wheeled base or destabilize a carried object. A door that is wide enough statically may still be unusable when its closing profile conflicts with the robot's crossing time.

Humanoids add a second envelope: the swept volume of arms, tools and payloads. An apparently clear torso path can leave an elbow exposed to shelving or a carried panel exposed to a door frame. Infrastructure models therefore need dynamic envelopes and direction-dependent constraints in addition to two-dimensional footprints.

Shared resources turn geometry into protocol. A lift, automatic door, tool cabinet or workcell needs a state model that answers practical questions: Who may request it? When is access committed? How is occupancy detected? What happens when acknowledgement is lost? Which party can cancel? How does a human override the reservation? A digital command without physical confirmation is weak evidence. A door controller may report “open” while an object blocks the passage. A robot should combine interface state with local sensing and defined timeouts.

Safety remains a system obligation. ISO 3691-4:2023 addresses safety requirements and verification for driverless industrial trucks and their systems, explicitly framing the vehicle together with its operating system context. Its scope does not automatically cover every humanoid or service robot, yet the systems view is instructive: routes, zones, controls and operating conditions influence the safety case alongside onboard protective functions (ISO/TC 110/SC 2 catalogue).

Charging is an operational contract

Battery capacity sets a theoretical endurance. Energy infrastructure determines available working time. The relevant metric is the probability that a robot reaches an appropriate energy service, connects successfully, receives the required power, leaves on schedule and returns to work with sufficient reserve.

Charging architecture follows the duty cycle. Fleets with predictable breaks may use scheduled conductive charging. High-utilization systems may exploit opportunity charging during natural idle periods. Battery exchange can reduce turnaround time while adding pack inventory, identification, balancing, mechanical handling and safety responsibilities. Autonomous docking saves labor and makes short charging events practical, although it converts alignment, contact condition and station availability into machine-controlled variables.

The dock needs a complete state machine. Approach begins only when the station is identified, available and compatible. Localization transitions from facility navigation to precise relative alignment. Contact or coupling is verified independently of commanded motion. Electrical negotiation establishes voltage, current and thermal limits. Energy transfer is monitored from both sides. Departure occurs after power is removed, the interface is safe, and the path is clear.

Figure 2 turns autonomous charging into an explicit sequence with controlled recovery branches.

A robust energy contract includes:

• robot, battery and charger identity;
• supported electrical limits and charging profile;
• state of charge, state of health, temperature and charge-acceptance constraints;
• mechanical alignment tolerance and coupling confirmation;
• reservation, priority, expected completion and release rules;
• isolation, overcurrent, thermal and emergency-stop behavior;
• evidence for delivered energy, interruptions and abnormal termination.

Scheduling must protect mission completion. A planner that sends every robot to charge at the same state-of-charge threshold can create a synchronized queue. Energy-aware orchestration predicts task demand, travel to a suitable dock, queue risk, charging time and the reserve needed for safe parking during a degraded event. Priority can reflect operational consequence: a robot carrying time-critical material may receive access before an idle inspection unit, while a thermally constrained battery may require immediate care despite low task priority.

Infrastructure also shapes battery size. Reliable opportunity charging can reduce onboard capacity, mass and actuation energy. That creates an efficiency cascade, but only when dock availability and charging continuity are measurable. A smaller battery linked to an unreliable station converts an efficiency gain into a fleet-wide common dependency.

Connectivity must fail predictably

A robot uses several networks at once. Local real-time control may remain inside the body. Facility wireless carries tasks, maps, fleet state and maintenance data. Wired interfaces connect docks, workcells and service stations. Edge services aggregate low-latency shared information. Cloud services may support analytics, model management and fleet-wide learning. Treating all traffic as one generic connection hides differences in timing, trust and failure consequence.

Bandwidth is rarely the only constraint. Handover delay, jitter, congestion, coverage shadows, certificate expiry, name resolution and dependency on remote identity services can interrupt a workflow even when nominal throughput is high. The architecture needs service classes defined by data age, availability, integrity and fallback behavior.

Offline behavior must be an engineered mode. The robot needs a bounded-dependence contract for each external service: what cached data remains valid, which actions may continue, how long authority lasts, where the robot waits, and how it resynchronizes. A stale map can be more dangerous than no map when it silently preserves a corridor that has become a restricted work zone.

Reconnection also deserves design attention. State accumulated on each side may conflict. A fleet manager may have reassigned a task; a lift reservation may have expired; a robot may have completed a locally permitted maneuver. Recovery needs versioned state, monotonic event identifiers, idempotent commands and explicit reconciliation. Network restoration alone does not restore operational truth.

OpenRMF illustrates the breadth of the coordination problem. Its core provides task queuing, conflict-free resource scheduling and fleet-adapter utilities, while a useful deployment connects those functions to multiple surrounding subsystems (OpenRMF documentation). This separation is architecturally important: a robot adapter translates capability; it should not disguise missing guarantees in the building or fleet service.

Orchestration allocates scarce space and time

A fleet manager does more than dispatch the nearest robot. It allocates shared resources under uncertainty. Corridors, lifts, chargers, loading stations, human handover points and workcells have capacity, direction, access rules and recovery time. A locally efficient decision can produce system congestion: the shortest route may cross a single-capacity lift; the nearest charger may attract a queue; a robot arriving early may block the only safe staging position.

Maps become operational contracts. Geometry describes traversability. Semantic layers identify speed limits, one-way paths, clean zones, human-priority areas, docking poses and prohibited loads. Temporal layers represent shifts, maintenance windows and temporary hazards. Governance layers identify who may change each element and when a fleet must accept the revision.

Figure 3 shows why orchestration must allocate space and time together: a longer open route can finish before a blocked short route.

Resource reservation needs leases rather than permanent assumptions. A lease grants access for a defined period, expires safely, and carries a recovery rule. The physical resource should confirm relevant state independently. This pattern works for lift cabins, narrow aisles, tools and high-power chargers. It also limits deadlock: if one robot disappears from the network, resources eventually return to a known state.

Task allocation becomes stronger when it considers capability and health. Payload, reach, tool availability, battery reserve, localization quality and maintenance state all affect whether a robot can complete a job. A capable fleet manager may select a slightly more distant machine because its end effector is already configured and its battery has enough margin to avoid a charging interruption. The optimization target is completed work within constraints.

Human operations need visible and controllable state. Workers should understand whether a robot is yielding, waiting for access, requesting help or entering a protected zone. Supervisors need authority to pause resources, change priorities and establish temporary exclusions. Clear physical cues and digital control views should represent the same underlying state. Conflicting indicators erode trust quickly.

Interoperability needs several layers

Mixed fleets make infrastructure investment more durable, but interoperability is often reduced to message syntax. A common message can report position while leaving map coordinates, timestamps, traffic rights, safety assumptions and error recovery incompatible. Useful interoperability combines semantic, behavioral and operational agreements.

VDA 5050 defines communication between automated guided vehicles and a master control, including orders, state and instant actions. The recommendation aims at a uniform interface for coordinating vehicles through a master control (VDA 5050 Version 2.0.0). MassRobotics approaches mixed-vendor visibility through an AMR interoperability specification and reference materials (MassRobotics AMR Interoperability Standard). Their scopes differ, which is useful: coordination commands and shared fleet observations solve related but distinct problems.

Vertical integration adds another interface. OPC UA for Robotics defines an information model intended to expose robot-system information toward higher-level systems; release 1.02 was published in September 2025 (OPC 40010-1). Such models can support consistent asset identity, status and diagnostics between robot cells and manufacturing IT. They do not automatically provide real-time vehicle traffic control.

Procurement should require scenario-based conformance evidence. A conformance suite needs normal exchanges, delayed packets, duplicated commands, restarts, expired reservations, map updates, unsupported capabilities and recovery after partial completion. The strongest interface contract defines what happens when a participant cannot comply.

The fleet creates a governed data estate

Mobile robots continuously observe workplaces. Cameras may capture people, screens and proprietary processes. Maps reveal facility layout. Task histories expose production cadence. Telemetry identifies weak equipment and operational bottlenecks. These data streams are valuable for safety, maintenance and learning; they also create privacy, security and commercial risk.

Data governance begins at acquisition. Every stream needs a purpose, owner, retention period, access policy and quality definition. Raw sensor data should not flow to the cloud merely because bandwidth is available. Local processing can extract events, features or health indicators while keeping sensitive observations inside the facility. Evidence needed for incident reconstruction may require protected pre-event and post-event windows, synchronized timestamps and integrity controls.

Ownership is insufficient without decision rights. The facility operator may own operational records, the robot supplier may need diagnostics, an integrator may manage maps, and a model provider may request learning data. Contracts should state who can collect, transform, combine, export, delete and use information to improve products. The EU Data Act creates harmonized rules on fair access to and use of data from connected products and related services, making data-access architecture a commercial as well as technical concern (Regulation (EU) 2023/2854).

Cybersecurity must span robot, infrastructure and service identities. A trusted internal radio network is an inadequate boundary when robots roam between access points and connect to building systems. NIST SP 800-207 frames zero trust around protecting resources and granting access through explicit policy instead of implicit network location (NIST SP 800-207). Applied to fleets, that means authenticated devices and services, least-privilege permissions, protected credentials, signed software, segmented resources and auditable policy decisions.

Figure 4 maps the authority boundaries crossed by operational data, evidence and model updates.

Updates are operational events. A fleet with mixed software versions may interpret maps or resource states differently. Rollout policy needs compatibility windows, staged deployment, rollback evidence and a rule for quarantining machines that cannot meet the current infrastructure contract. Model updates require the same discipline: identity, validation scope and deployment authority should travel with the model.

Commission the system, measure the economics

Commissioning proves that robot and environment work together under realistic conditions. A successful route in an empty building says little about shift change, radio congestion, blocked chargers or a lift restarting mid-mission. Acceptance testing should exercise boundaries and recovery paths before production depends on them.

A practical commissioning program covers:

• surveyed geometry, dynamic clearances and localization quality under changing light and traffic;
• wireless coverage, roaming, congestion and deliberate service interruption;
• resource state machines for doors, lifts, docks, tools and workcells;
• charging compatibility, queue behavior, incomplete coupling and thermal limits;
• map and configuration version control across robots, fleet services and building interfaces;
• human override, emergency response, degraded operation and deterministic recommissioning;
• evidence capture, clock synchronization, cybersecurity events and recovery ownership.

Digital twins can support the process when their limits are explicit. The ISO 23247 series provides a framework for digital twins of observable manufacturing elements, including equipment, personnel and materials (ISO 23247-1:2021). A facility twin can test routes, resource conflicts and fleet policies before deployment. Its value depends on maintained geometry, behavior and timing assumptions. A visually accurate model with obsolete door timing remains an unreliable operational model.

The business case should measure completed useful work and interruption burden. Robot utilization alone can reward motion without value. Better indicators include successful missions per scheduled hour, human interventions per hundred missions, charging wait, resource-blocking time, mean recovery time, energy per completed task, maintenance labor and lost production caused by infrastructure dependencies.

Environmental adaptation has a lifecycle cost, yet it can lower robot complexity and fleet size. The economic comparison should include infrastructure engineering, integration, cybersecurity, service contracts, facility downtime, spare capacity and future vendor change. A standardized lift gateway may look expensive beside manual button pressing until repeated failures, slower passage and support labor are counted across several robots and years.

Responsibility must be visible when a mission fails. Robot vendor, fleet software provider, facility IT, operational technology team, building operator and systems integrator may all hold part of the causal chain. Shared observability, synchronized event records and explicit support boundaries shorten recovery. Without them, every incident becomes a negotiation about whose dashboard is correct.

Continuity is designed through scenarios

Availability figures conceal the sequence that matters. A fleet service may meet a high annual uptime target while a five-minute interruption at shift start prevents dozens of robots from accepting work. A charger can be electrically available while its docking area is occupied by an abandoned pallet. A lift gateway can answer health checks while its reservation database has lost the robot already inside the cabin. Continuity engineering follows the mission through these combinations.

Scenario design begins with operational states. During normal production, all services may be present. During local degradation, a robot may lose wireless coverage while retaining perception, map and motion capability. During coordinated degradation, a building service and fleet manager may disagree about resource ownership. During emergency operation, human responders may override traffic rules and isolate power domains. During restoration, components return at different times with different memories of what occurred.

Each scenario needs four decisions: permitted action, forbidden action, evidence required to continue, and destination if confidence expires. A robot carrying a stable, low-consequence load might finish crossing an already reserved aisle after network loss. The same machine approaching a lift should stop before entry if cabin identity and reservation cannot be confirmed. A humanoid holding a heavy component may need enough local authority to place it safely before yielding to a remote stop request. The correct response depends on physical state and consequence, not connectivity status alone.

Cached information receives an explicit validity envelope. A static floor map may remain useful for hours, while a temporary exclusion zone can become unsafe within seconds. Tool identity might stay valid until a release sensor changes state. A lift reservation may expire after one missed acknowledgement. Encoding these horizons makes data age visible to planning and control instead of leaving stale context to look authoritative.

Restoration creates its own hazards. When fleet control returns, queued commands can arrive after their operational purpose has disappeared. Duplicate work orders can cause repeated pickup. A robot may report a completed local action against a task that the server has already reassigned. Recovery therefore uses idempotent operations, versioned tasks and reconciliation rules. Physical state remains the final evidence: software must not infer an empty gripper, clear aisle or released charger solely from an old transaction record.

Exercises should include failures that cross organizational boundaries. Facility IT can disable an access point while operations observes robot behavior. The building team can restart a lift controller while the fleet manager holds active reservations. Maintenance can replace a charger module with a different firmware version. Cybersecurity can revoke a certificate during a mission. These tests reveal undocumented dependencies and clarify who has authority to restore service.

Continuity capacity also has a cost. Safe waiting positions consume floor area. Local caches require secure storage. Redundant edge services consume power and maintenance effort. Spare chargers reduce queue sensitivity. The investment is justified against the consequence of interruption, not through redundancy as a general virtue. A low-criticality cleaning fleet may accept delayed work. A robot supplying a constrained production cell may require local failover and reserved energy margin.

Ownership follows the dependency graph

The external operating system crosses conventional organizational boundaries. Facilities own doors, lifts and power distribution. Operational technology teams protect production networks and workcell interfaces. Information technology teams manage identity, wireless access and enterprise services. Robot suppliers maintain embedded software and diagnostics. Integrators connect the pieces. Operations owns the outcome and often has the least direct control over the underlying stack.

A responsibility matrix built around products will miss shared failure modes. Accountability should follow operational capabilities: safe passage through a door, successful energy service, valid map distribution, conflict-free resource allocation, protected update deployment and incident reconstruction. For each capability, one party must own the end-to-end outcome even when several suppliers contribute components.

Interface ownership includes change management. A facilities contractor may update a lift controller without realizing that timing changes affect robot reservations. A robot supplier may alter localization behavior and invalidate docking tolerances. An IT certificate policy may shorten credential lifetime beyond the fleet's offline service interval. Change review should identify dependent capabilities, compatibility windows, rollback conditions and required recommissioning tests.

Service-level agreements become more useful when written in operational terms. “Network availability” says little about handover behavior in a critical corridor. “Charger uptime” ignores repeated coupling failures. “Fleet service response time” can exclude the building gateway that blocks completion. Measures should capture successful crossings, energy-service completion, reservation consistency and recovery time at the points where work depends on them.

Lifecycle asymmetry deserves an explicit plan. A facility may operate for thirty years while robot generations turn over in five. Gateways, coordinate frames and resource models need stable identities and migration paths. Replaceable adapters can absorb protocol evolution, but every adapter also becomes a maintained software product with security updates, test evidence and an owner. Open interfaces reduce switching friction only when their semantics, conformance tests and operational behavior remain controlled.

The result is a living dependency register. It links capabilities to physical resources, services, interfaces, versions, owners and recovery procedures. During procurement it exposes lock-in. During commissioning it defines tests. During operation it guides incident response. During replacement it reveals which assumptions the new machine must satisfy. The register turns infrastructure from background circumstance into an engineered fleet asset.

Autonomy becomes an architectural property

The world around a robot should offer leverage without creating invisible dependence. Physical adaptations make repeated transitions reliable. Energy services turn battery capacity into availability. Connectivity carries shared state while bounded local authority preserves safety. Orchestration converts corridors, chargers and workcells into allocatable resources. Governance protects the data and decisions that accumulate around the fleet.

The decisive design question is simple: what must still work when one surrounding service disappears? Every external dependency needs a validity period, a degradation contract, a safe waiting condition and a recovery owner. These rules allow infrastructure to increase capability without quietly acquiring unlimited authority over the machine.

Over time, the building may influence more of the robot's behavior. It can redirect traffic, restrict zones, delay charging, distribute maps and authorize tasks. That power can improve safety and productivity. It also concentrates operational control in services that may be owned by different parties. The architecture should make those decisions attributable, constrained and reversible.

A productive robot fleet is a federation of physical and digital systems operating through explicit contracts. The robot brings adaptable intelligence to the job. The environment supplies dependable energy, access, context and coordination. Their boundary determines whether autonomy remains a demonstration or becomes infrastructure.