Abstract
A dependable robot operates through a hierarchy of compute domains. Their placement determines what the machine can perceive, how quickly it can react, which faults it can contain and whether capable algorithms remain subordinate to physical limits. Sensor-edge, joint, zonal, safety, central-AI and infrastructure compute carry distinct latency, jitter, data-age, memory, power, thermal, safety and cybersecurity obligations. Fast physical loops belong to local deterministic controllers; zones coordinate axes and reduce data; heterogeneous central compute handles semantic perception and planning; independent safety domains enforce constraints; and off-board infrastructure supports fleet learning, simulation and lifecycle services. Sensing interfaces, microcontrollers, processors, accelerators, memories, network devices, secure elements, power management and monitoring devices consequently form one coordinated semiconductor architecture. Dependability emerges when authority, timing and evidence are engineered across the hierarchy.
1. The Machine Reacted Before the Model Finished
A manipulator meets an unexpected obstruction. The wrist force estimate changes first. A joint controller limits torque within its next control interval. A zonal controller detects the altered contact pattern and redistributes motion. Milliseconds later, central perception identifies the obstruction as a person’s arm. A remote service never enters the causal chain.
The sequence exposes the central architectural fact: physical intelligence is distributed by deadline and authority. A large accelerator can classify the scene with impressive accuracy while remaining too distant, too variable or too failure-prone to close the fastest loop. A small microcontroller beside the motor can apply a current limit with modest computational resources because it owns timely measurements, a bounded control law and direct access to the power stage.
Compute placement is governed by more than TOPS, core count or model size. Each function belongs where five conditions can be satisfied simultaneously: its inputs arrive with known age; execution completes within a defensible bound; outputs reach the controlled element in time; faults are contained; and energy plus heat remain supportable through the mission. Networking and software middleware connect the hierarchy while physical distance, scheduler interference, memory-copy cost and power-rail failures remain real constraints.
The resulting hierarchy has six levels: sensor edge, joint or actuator control, zonal control, independent safety and trust domains, central AI compute, and off-board infrastructure. A product may combine boundaries physically while preserving their responsibilities. Timing, safety and authority contracts remain explicit even when several functions share one package or board.
Figure 1 summarizes the governing gradient: physical consequence is strongest near sensing and actuation, while semantic scope expands toward central and off-board compute.
Visual pending: Chapter figure 35
2. Placement Begins with a Workload Contract
A workload contract describes what a computation consumes, produces and may influence. It includes the worst credible input rate, data volume, execution demand, output deadline, tolerated jitter, startup state, failure response and security classification. For physical systems, the contract also states the maximum age of every decisive input. A result computed quickly from stale data can be operationally wrong while every processor metric appears healthy.
For a periodic function, a useful first-order end-to-end constraint is:
Tacq + Tqueue + Ttransfer + Texec + Tact + J ≤ D,
where acquisition, queueing, transfer, execution and actuation delays plus aggregate jitter must remain within deadline D. Average latency is insufficient for a protective or stabilizing loop. The relevant value is a justified upper bound under defined load, fault and temperature conditions.
| Workload class | Dominant constraint | Typical placement | Permissible fallback |
|---|---|---|---|
| Current regulation and commutation | Microsecond-scale timing, low jitter, direct sensing | Joint or motor controller | Controlled torque removal or local safe state |
| Torque, impedance and contact control | Fresh state, deterministic execution | Joint and zonal domains | Reduced force, speed or stiffness envelope |
| Whole-body estimation and coordination | Time-correlated multi-sensor state | Zonal or central real-time compute | Posture hold, stable stop or reduced mobility |
| Perception and semantic planning | Throughput, memory bandwidth, model latency | Central heterogeneous compute | Validated local behavior set |
| Fleet optimization and model training | Scale, storage, aggregate data | Local infrastructure or cloud | Continue mission with cached policy and local limits |
The contract also separates proposal from authority. A planner may propose a trajectory. Real-time controllers verify dynamic feasibility; safety functions enforce independent limits; power electronics decide whether available voltage, current and temperature support the command. This bounded-authority pattern allows sophisticated AI without giving a probabilistic model unmediated control of stored electrical energy.
2.1 Deadline, Criticality and Rate Are Different Axes
High data rate does not imply high control criticality. A multi-camera perception system may generate gigabits per second while tolerating the loss of selected frames. A low-bandwidth emergency input may contain only one bit yet require an independent path, persistent diagnostics and immediate action. Architecture reviews that sort workloads only by bandwidth systematically misplace authority.
Deadline and update rate also differ. A sensor may publish at 1 kHz with a 5 ms deadline, allowing controlled queueing and fusion. Another function may execute at 100 Hz while requiring every result within 2 ms of a synchronized trigger. The former stresses sustained throughput; the latter stresses response-time bounds. Jitter consumes the timing margin available for estimation, communication and actuation. An explicit jitter budget keeps that consumption visible beside the nominal cycle time.
Criticality determines what evidence and independence are required. A dropped visualization frame may be logged. A missed torque-limit update may require immediate containment. Mixed-criticality processors can host both, provided scheduling, memory bandwidth, DMA traffic, caches, interrupts and accelerators are partitioned or bounded. Spatial isolation alone is incomplete when two domains compete for the same DRAM controller or thermal envelope.
2.2 Placement Is Also a Recovery Decision
Every placement creates a recovery boundary. Restarting a central perception container can be acceptable while joints retain safe commands and zones preserve balance-related state. Restarting a motor-control process may require torque removal, brake coordination and mechanical requalification. The architecture must define which state survives, which state is reconstructed and which authority remains inhibited until checks complete.
Recovery time objectives therefore belong beside execution deadlines. A function that normally completes in one millisecond may take seconds to reinitialize models, rebuild maps or authenticate dependencies after a fault. Redundancy, warm standby, checkpointing and locally cached state address different parts of this interval. Their value should be measured against the physical trajectory the robot can sustain during recovery.
3. Sensor Edge and Joint Compute: Where Physics Becomes Data
The sensor edge determines whether later computation receives evidence or merely numbers. Analog front ends, converters and local processors perform excitation, filtering, linearization, timestamping, calibration selection, plausibility checks and event extraction. Cameras and lidars may execute early image-signal processing; tactile arrays may suppress unchanged taxels; encoders may attach quality flags; inertial sensors may preintegrate observations. Local reduction lowers bandwidth, but irreversible compression can destroy evidence required for diagnosis or learning. Raw or minimally processed windows therefore need selective preservation around anomalies.
Acquisition timestamps should be created as close as practical to the physical sample. Receipt time at a central processor mixes sensor delay, network delay and queueing into one ambiguous value. Distributed time synchronization, explicit clock uncertainty and sequence integrity allow state estimators to distinguish an old observation from a new physical event.
Joint compute closes the electromechanical loop. A typical channel couples position and current sensing, pulse-width modulation, gate-drive supervision, field-oriented control, torque estimation, thermal state and local diagnostics. Motor-control deadlines and power-stage protection favor microcontrollers or real-time processors with tightly coupled memory, deterministic peripherals and hardware timers. Accelerator-class AI devices rarely own these responsibilities directly because caches, virtual memory, shared interconnects and complex operating systems enlarge the timing proof.
Local autonomy must remain bounded. A joint controller can limit current, reject a stale command, transition to a defined state and report health. It should not invent a mission objective. Conversely, central compute should not bypass local electrical containment. The interface between them is an action contract containing command value, validity interval, permitted mode, sequence identity and constraints. Timeout semantics matter as much as the command itself.
Semiconductor selection follows the channel responsibilities: low-noise sensing and conversion; microcontroller compute; isolated or non-isolated gate driving; power switches; position interfaces; temperature and current monitors; local communication PHYs; and power management. Integration can reduce area and wiring, while partitioning may improve thermal separation, repairability and fault containment. The correct boundary depends on joint power, cable length, environment, service concept and required diagnostic independence.
4. Zonal Compute: The Robot’s Missing Middle
The zonal layer solves several awkward architectural problems between joints and central AI. A limb, torso or mobile base contains signals with shared mechanical context and short physical paths. A zonal controller aggregates them, aligns time, performs sensor fusion, coordinates several axes, monitors local energy and reduces upstream traffic.
For a humanoid leg, zonal computation may combine joint positions, motor currents, foot contact, inertial motion and local thermal state. It can estimate contact confidence and actuator margin before forwarding a compact state to whole-body control. If the backbone is interrupted, the same domain can execute a validated fallback trajectory or controlled stop. Such behavior transforms the network from a single failure line into a managed dependency.
Zonal architecture also changes the harness. Distributed motor drives reduce high-current phase-cable length but add electronics near heat and vibration. Centralized inverters simplify joints but increase copper, electromagnetic coupling and connector burden. Zonal power and data distribution can mediate these extremes. The computation boundary, power-conversion boundary and service boundary should be co-designed because moving only one tends to relocate mass and failure exposure elsewhere.
A zone commonly needs deterministic multi-core microcontrollers or real-time application processors, Ethernet or industrial-network switches and PHYs, local nonvolatile memory, monitored power rails, watchdogs and secure identity. It may include an AI accelerator for localized perception, yet its defining role is coordination with bounded response. The zone earns its place when it reduces harness complexity, contains faults, improves timing or supports graceful degradation. A processor that delivers none of these gains adds software and thermal burden.
Figure 2 shows the zonal boundary for a humanoid leg, including time alignment, multi-axis coordination and a local fallback path.
Visual pending: Chapter figure 36
5. Safety Islands and Trust Boundaries
Dependable robots require a compute domain able to question the rest of the machine. It observes selected commands, states and diagnostics; evaluates invariants; and can constrain or remove physical authority without reproducing central intelligence. This safety island may be a dedicated controller, an isolated core cluster, a companion device or a distributed set of monitors. Independence arises from power, clock, memory, software and communication choices.
Industrial-robot safety requirements distinguish robot design from application integration; ISO 10218-1:2025 addresses the robot, while ISO 10218-2:2025 addresses applications and cells [1], [2]. Mobile and humanoid robots may fall under additional standards according to use, environment and intended contact. The architectural lesson remains stable: risk reduction starts with defined hazards, operating modes and safety functions. Compliance depends on the complete risk-reduction architecture and its evidence; a generic “safety processor” supplies only one possible element.
The safety domain should receive evidence through explicit paths: measured speed and position, enable state, power-stage status, communication health, selected contact information and emergency inputs. It verifies limits appropriate to mode and configuration. When central AI misses a deadline, produces an infeasible request or loses confidence, the safety response may be a speed reduction, torque limitation, posture transition, controlled stop or power isolation. A legged robot can require active control to reach a risk-reduced condition, so immediate de-energization is not universally the safest first response.
Cybersecurity boundaries intersect with safety. NIST’s zero-trust architecture moves protection from implicit network location toward users, assets and resources [3]. Inside a robot, the practical translation is authenticated identity, least privilege, measured startup, signed software, protected keys, segmented communication and policy at each authority transition. Zephyr’s user-mode model illustrates memory isolation in which untrusted threads are separated from other user threads and the kernel [4]. Similar mechanisms in real-time operating systems, hypervisors and system-on-chips can contain faults, provided configuration and shared-resource interference are assessed.
Safety and security monitors must remain observable. A rejected command should yield a causal record: request identity, measured state, violated constraint, software configuration and resulting action. Without this evidence, a fleet may repeatedly classify deliberate containment as unexplained malfunction.
6. Central AI Compute: Throughput Meets Heat
Central compute combines high-rate perception, world modeling, localization, semantic reasoning, motion planning, human interaction and policy inference. These workloads favor heterogeneous processors: CPUs for orchestration and irregular logic, GPUs for dense parallel operations, neural-processing units for efficient inference, vision accelerators for imaging pipelines, and real-time cores for bounded coordination. Arm describes heterogeneous AI platforms as integrations of CPUs, GPUs and NPUs optimized for distinct workload classes [5].
The decisive resource is frequently memory movement. A camera frame may be captured, transformed, copied into accelerator memory, converted between layouts, fused with other tensors and copied again for planning. Each movement consumes bandwidth and energy and can add variable delay. Zero-copy mechanisms, shared buffers and accelerator-local reuse help, but they demand disciplined ownership, cache coherence and lifetime management. Peak arithmetic throughput is valuable only when the data path can feed it.
Power modes make the trade visible. NVIDIA’s Jetson documentation exposes software-visible power, thermal and electrical management features for Orin-class devices [6]. Those figures apply to the documented products and configurations. The underlying mechanism is representative: compute capacity depends on configured power envelopes, clocks, active engines and thermal conditions. A cold-bench benchmark at maximum mode provides incomplete evidence for sustained operation inside a sealed torso beside converters and batteries.
Thermal design therefore enters scheduling. The central computer can prioritize perception during fast motion, reduce model rate during stable operation, migrate selected preprocessing to zones, and preserve reserve for anomalies. Thermal throttling must be treated as a known operating state with measured impact on deadlines. If a safety-relevant perception function loses its timing guarantee under throttling, the robot needs a corresponding reduced operating envelope.
Central AI also carries a larger software attack surface. Rich operating systems, containers, model runtimes, device drivers and update agents increase capability, maintenance speed and dependency depth. Hardware memory protection, IOMMU isolation, secure boot, measured boot, authenticated update and protected rollback state should align with the physical authority of each service. A compromised logging container must not gain a route to joint torque.
Figure 3 traces a representative perception pipeline and makes the hidden coupling among data copies, bandwidth, deadlines and heat visible.
Visual pending: Chapter figure 37
7. Networks Turn Placement into a System
A compute hierarchy is only as dependable as the semantics of its links. Bandwidth states how much data can move; timing, freshness and loss behavior require separate contracts. OMG’s Data Distribution Service was designed for publish-subscribe communication in real-time and embedded systems [7]. ROS 2 exposes middleware quality-of-service policies including reliability, durability, history and queue depth [8]. Their value depends on application behavior and network capacity engineered to match them.
Time-Sensitive Networking provides Ethernet mechanisms for synchronized time, scheduled traffic, shaping, filtering and policing. IEEE describes TSN as carrying time-critical and other traffic on shared networks with bounded latency, low delay variation and low packet loss [9]. The IEEE 802.1 TSN portfolio includes timing and synchronization within 802.1AS and traffic-control mechanisms consolidated into the 802.1Q base standard [10]. Switch configuration, endpoint behavior, clock design, traffic admission and worst-case validation determine the end-to-end guarantee.
Traffic should be classified by consequence:
- Control traffic needs bounded latency, freshness and timeout behavior.
- State traffic needs synchronized acquisition and explicit quality.
- Perception streams need high bandwidth and controlled congestion behavior.
- Diagnostic and logging traffic needs integrity and must yield to physical deadlines.
- Update and model traffic needs authentication, staging, rollback and strict authority separation.
Network loss should trigger a defined degradation contract at every boundary. A joint may hold the last command only for a short validity interval. A zone may complete a locally safe transition. Central compute may continue with partial sensing at reduced speed. Remote connectivity may disappear with no immediate effect on physical control. Such asymmetry is intentional: dependency on a service should shrink as its distance and variability increase.
7.1 Time Is a Shared Measurement
Clock synchronization is part of sensing architecture. Fusion algorithms compare observations under the assumption that timestamps refer to a common timeline. A clock offset can appear as a spatial error when the robot moves; drift can create an error that grows during a mission. The system should monitor synchronization state, clock uncertainty and discontinuities, then propagate that quality into state estimates.
A network can deliver a packet within its latency budget and still deliver information that is too old. Queue depth, sensor exposure, preprocessing and retransmission all contribute to age. Lifespan policies can prevent stale data from being consumed, while deadline and liveliness policies reveal absent updates. Application logic must connect these events to physical behavior. Middleware can announce that a publisher is late; only the robot architecture can decide whether to slow, stop or switch evidence sources.
7.2 Congestion Must Fail Predictably
Diagnostic bursts are especially dangerous because they often accompany faults, precisely when control traffic needs its strongest guarantee. Stream policing, reserved capacity and priority design should prevent a failing node or verbose logger from consuming the backbone. This is also a cybersecurity control: a compromised endpoint should not gain physical influence merely by flooding a shared link.
Redundant links help only when their common dependencies are understood. Two Ethernet paths through the same connector, switch power rail or software driver may fail together. Diversity can involve route, power, clock, implementation and sensing principle. The required degree follows from hazard analysis and mission availability, not from a generic preference for duplicate hardware.
8. Local Infrastructure and Cloud: Powerful, Deliberately Nonessential
Off-board compute extends the robot through maps, fleet orchestration, simulation, large-model services, software distribution, telemetry analysis and training. A factory edge server can offer lower and more predictable latency than a public cloud, while the cloud offers elastic storage and aggregate learning across sites. Collision avoidance, balance and electrical protection remain governed by bounded on-robot paths.
The correct split depends on interruption tolerance. Mission allocation can often survive seconds of delay. Semantic assistance may survive hundreds of milliseconds if the robot can pause. Whole-body stabilization cannot. A remote planner may propose goals or trajectories, but the robot must validate them against current geometry, energy, health and authority. Locally cached maps, credentials, policies and fallback behaviors determine whether connectivity loss causes a graceful reduction or an operational cliff.
Data governance constrains upload as strongly as bandwidth. Cameras, microphones and manipulation logs may capture people, proprietary processes and sensitive locations. Data minimization should occur near acquisition: extract events, redact identifiers, retain only justified windows and bind records to policy. Fleet learning requires configuration provenance so observations can be related to hardware revision, calibration, model and environmental context.
Updates are a return path from cloud to physics. A signed model can still be operationally unsafe for a specific robot configuration. Deployment therefore requires compatibility checks, staged rollout, health monitoring, rollback protection and a deployment authority record defining where and under which constraints the artifact may run. The cloud can distribute capability; the robot must retain the final admission decision for physical execution.
9. Semiconductor Architecture Follows Responsibility
The hierarchy maps to semiconductor classes without implying a single vendor or fixed partition. Sensor edges need analog and mixed-signal precision, converters, timing and low-power embedded processing. Joints need real-time microcontrollers, motor-control peripherals, gate drivers, switches and current or position sensing. Zones need deterministic multi-core control, switching, security and monitored power. Central compute needs heterogeneous processors, high-bandwidth memory interfaces, storage and high-speed networking. Safety and trust domains need independent controllers, hardware security, watchdogs and protected memories. Every layer needs power conversion and telemetry appropriate to its state.
| Architecture responsibility | Enabling semiconductor capability | Key selection evidence |
|---|---|---|
| Fresh physical measurement | AFE, ADC, sensor interface, timestamp hardware | Noise, drift, synchronization, diagnostic behavior |
| Bounded actuation | Real-time MCU, timer/PWM, gate driver, power switch | Worst-case execution, protection latency, thermal margin |
| Zonal coordination | Multi-core MCU/MPU, Ethernet switch/PHY, local memory | Jitter, isolation, traffic handling, degraded operation |
| AI perception and planning | CPU/GPU/NPU/vision accelerator, DRAM, storage | Sustained model latency, memory bandwidth, energy per task |
| Trust and containment | Secure element/HSM, safety MCU, watchdog, protected NVM | Key protection, startup evidence, independence, fault response |
Benchmarking should use mission traces that exercise concurrent workloads. Measurements include end-to-end latency distributions, data age, dropped deadlines, memory bandwidth, rail power, temperatures and recovery behavior. Tests at environmental extremes and under injected faults expose the real architecture: nominal inference throughput loses practical value when logging traffic causes a network deadline miss.
9.1 Selection Evidence Across the Lifecycle
Component qualification begins with electrical and timing limits, then expands into software support and lifecycle evidence. A processor may have adequate performance yet depend on a driver stack that cannot expose deterministic scheduling or secure update. A network device may support TSN features while lacking the configuration, diagnostics or timestamp interfaces needed by the system. A secure element may protect keys but leave software configuration provenance unresolved.
Manufacturing and service add further constraints. Device identity must be provisioned without exposing secrets. Calibration must bind values to the correct sensor, joint and mechanical configuration. Replacement modules need authenticated configuration transfer and safe recommissioning. Fault logs require monotonic time or a defensible reconstruction method after complete power loss. These responsibilities influence nonvolatile memory, hardware security, clocking and diagnostic interfaces long before a robot reaches a customer site.
Supply continuity also interacts with architecture. Interfaces that are explicitly specified and conformance-tested make substitution more feasible. Hidden dependence on a proprietary accelerator operator, undocumented timing behavior or one memory geometry can convert a component shortage into a platform redesign. Portability has a measurable cost in abstraction and validation, yet it can preserve the product line across silicon generations.
9.2 Evidence-Capped Performance Claims
Compute claims should identify model, precision, batch size, input shape, software version, power mode and temperature. Control claims should identify cycle period, worst-case execution conditions, concurrent interrupts and communication load. Network claims should identify topology, frame sizes, traffic classes, clock state and failure assumptions. Energy claims should include the complete rail boundary so that accelerator efficiency is not separated from memory and conversion losses.
Evidence discipline keeps attractive numbers within compatible boundaries. Accelerator throughput alone cannot predict perception latency; perception latency alone cannot predict action latency; nominal action latency alone cannot establish safe behavior after a fault. A defensible end-to-end claim combines measured and bounded contributions while keeping residual uncertainty visible.
Figure 4 condenses the placement logic into six decision dimensions spanning deadline, data age, authority, failure autonomy, memory demand, and energy or heat.
Visual pending: Chapter figure 38
10. Engineering Rules for a Dependable Compute Continuum
Five rules summarize the placement method.
- Place authority near the physical consequence. Fast electrical and mechanical constraints belong where sensing and actuation remain available during upstream failure.
- Move meaning upward and limits downward. Edge and zones convert signals into trustworthy state; central intelligence sends bounded objectives while local controllers retain raw power authority.
- Design every remote dependency with an expiry. Commands, maps, credentials, models and cached state need validity conditions and fallback behavior.
- Budget memory movement and heat with computation. Sustained performance depends on data paths, power delivery and cooling, not peak arithmetic alone.
- Preserve causal evidence. Time, configuration, command provenance and constraint interventions must survive well enough to reconstruct consequential events.
The architecture should be reviewed as a matrix of functions against compute domains. Each cell records responsibility, input age, deadline, authority, failure response, security boundary and evidence output. Gaps become visible quickly: a central planner with no local timeout; a safety monitor sharing the same clock and power rail as the function it supervises; a camera pipeline with no acquisition timestamp; an update service with no configuration admission check.
The dependable robot is a federation of bounded computers. Its smallest controllers protect the immediacy of physics. Zones preserve coordination when the backbone degrades. Central processors provide semantic intelligence within power and thermal limits. Safety and trust domains police authority. Infrastructure beyond the robot improves the fleet without becoming a hidden balance controller. The machine becomes capable because these domains cooperate, and dependable because each knows what it may do when the others fall silent.
