Arm Total Design for Physical AI: 80+ Partners, Six Levels of Robot Capability

Arm Holdings is attempting to do for the robotics industry what SAE International's autonomy levels did for self-driving cars — give a fragmented field a shared vocabulary for describing what machines can actually do. On September 8, the Cambridge-based chip IP licensor launched Arm Total Design for Physical AI, a coordinated ecosystem program drawing in more than 80 companies across the robotics and autonomous-systems technology stack, and simultaneously introduced a Robotics Capability Framework that defines six ascending levels of robotic sophistication, from reactive rule-followers to systems that learn and self-optimize over time.

In an interview with The Robot Report, Arm Vice President Dermot O'Driscoll described the program as filling a gap he observed when he joined the company's physical AI division earlier this year: companies ready to build on Arm architecture but unable to find partners, align on interoperability expectations, or efficiently integrate the hardware, software, sensors, and actuators a deployable robot requires.

Arm's Business Model Makes It the Logical Ecosystem Coordinator

Arm does not manufacture chips. It licenses processor architecture — earning royalties each time a chip based on its designs ships in a product. That model makes Arm uniquely motivated to reduce friction across the entire physical AI supply chain: every successfully deployed robot built on Arm architecture is a royalty event across silicon, software, and cloud layers.

The company projects physical AI will represent a $200 billion annual compute opportunity by the 2030s, per Arm's own estimates. The figure reflects a broadly shared conviction in the semiconductor industry that robots, autonomous vehicles, and industrial machines represent the next major compute demand wave after cloud AI.

Arm already built a comparable program for cloud infrastructure. O'Driscoll said that experience directly informed the physical AI program's structure. "We built that in the cloud ecosystem, and then when I moved over to the physical AI space in March, I noticed that we had the same gap," he told The Robot Report. The distinction, he acknowledged, is that physical AI is harder: a cloud server runs controlled software in a known environment, while a robot must integrate vision, proprioception, real-time control, actuator feedback, and safety-critical fault management in an unpredictable physical world.

Six Levels of Robot Capability: RL0 to RL5

The Robotics Capability Framework defines its six levels along axes of behavior complexity, decision autonomy, environmental adaptability, and the system-level requirements each tier demands in latency, compute placement, memory, power, and safety assurance.

At RL0, a robot reacts to stimuli and executes commands but adheres to fixed rules — a warehouse sorter or a pre-programmed pick-and-place arm. At RL1, the system processes sensor data and adapts within defined parameters without human re-programming, such as re-planning around an unexpected obstacle. By RL2, AI-powered reasoning lets the robot interpret complex situations and select from a broader learned behavioral repertoire. RL3 adds collaborative capacity: the robot coordinates with humans or other machines and shares contextual state. RL4 represents full operational autonomy across changing environments. RL5 describes systems with evolving behavior that actively learn from experience and self-optimize strategies.

Arm's chief architect Richard Grisenthwaite published a manifesto explaining the rationale: without consistent definitions, vendor claims that a robot is "autonomous" or uses "physical AI" carry no reliable meaning across purchase negotiations, regulatory review, or insurance underwriting. The framework is explicitly architecture-agnostic — designed to apply to robots regardless of whose compute they run on.

The RCF took explicit inspiration from SAE International's J3016 levels of driving automation. O'Driscoll noted that robotics is more complex — vehicles operate in a relatively constrained domain of roads and traffic rules, while robots operate across manufacturing floors, hospitals, construction sites, and open terrain — making the framework necessarily multi-dimensional.

What the Framework Is Not Yet

The RCF defines categories but does not yet specify the metrics, test conditions, or pass/fail thresholds that would let a third party independently verify that a given robot belongs at a given level. Independent analysts have noted this distinction: a shared vocabulary improves requirements writing and vendor comparison, but reproducible cross-vendor evaluation requires published benchmarks, validated datasets, and conformance procedures — none of which Arm has specified yet. The SAE analogy reinforces the concern: L3 and L4 automotive levels became practically useful only after ISO and SAE developed follow-on technical standards with specific performance metrics and operational design domain requirements.

Arm is inviting the industry to co-develop the RCF further. Collaboration sessions with program members are planned to begin in the coming months.

The Compute Foundation: Arm Zena CSS

The Arm Zena Compute Subsystem (Zena CSS) underpins the physical AI ecosystem's compute layer. Built on the Armv9 Automotive Enhanced (AE) architecture, Zena CSS integrates 16 Cortex-A720AE application cores for ADAS and in-vehicle infotainment workloads, a dedicated Safety Island built on a lock-stepped Cortex-R82AE cluster with ASIL D diagnostic capability, and a Runtime Security Engine targeting ASIL B. Optional image signal processing is available through Mali-C720AE and Mali GPU for surround-view and driver-monitoring applications.

Arm claims Zena CSS accelerates automotive SoC development by up to 12 months and reduces silicon engineering effort by up to 20% through pre-integration and pre-validation work done before customers begin their own design cycles. The Total Design program is positioned as the ecosystem layer above this foundation: Zena CSS provides the validated compute platform; program partners provide interoperable software stacks, AI models, sensors, actuators, and system integration. Arm cited one concrete joint output: Arm, AWS, Google, HERE, RemotiveLabs, and Siemens co-developed an integrated digital cockpit reference solution validated on Zena CSS before final silicon was available.

The NVIDIA Complication in Arm's Partner List

Among the 80+ founding members is Hugging Face, the AI model platform hosting more than 3 million open-source models used by over 200,000 companies and 18 million developers. Arm listed Hugging Face as a key partner for providing robotics teams access to open-weight vision, language, and manipulation models.

Six days before Arm's September 8 announcement, NVIDIA filed an SEC 8-K disclosing its agreement to acquire Hugging Face for approximately $12.93 billion, with the transaction expected to close in the first half of 2027, pending regulatory approval. NVIDIA's Isaac platform — Isaac ROS, Isaac Sim, and Isaac Foundation Models — is the primary architectural competitor to Arm's ecosystem approach in physical AI compute. NVIDIA's GPU hardware dominates AI training and robotics inference workloads where high parallelism outperforms CPU and NPU architectures.

Arm listed Hugging Face after the acquisition announcement was already public. Jensen Huang committed to keeping Hugging Face an open, multi-cloud, multi-accelerator platform with no requirement to use NVIDIA compute. Whether that neutrality holds as NVIDIA deepens its physical AI stack — and whether enterprise buyers treat an NVIDIA-owned Hugging Face as a genuinely neutral partner in an Arm ecosystem — is a question that the pending deal cannot yet answer.

Read more: NVIDIA's pending $12.9 billion acquisition of Hugging Face

What 80 Partners Span and What Interoperability Delivers

The program's founding members cover layers that a functional autonomous system requires: NXP and ECARX on silicon, QNX (BlackBerry's automotive RTOS subsidiary) on safety operating systems, Liquid AI and Qwen on AI model inference, AWS on cloud infrastructure, Siemens on industrial automation software, Unitree Robotics and PSYONIC on end hardware systems. Companies contributing to the RCF specification itself include ANYbotics, Fourier, GALBOT, Gravis Robotics, McKinsey, and Robotec.ai.

O'Driscoll identified the practical value clearly: when an OEM building an industrial robot can verify that components from multiple ecosystem members already interoperate on a known compute platform, integration effort drops substantially relative to certifying each component independently. That integration friction — not component cost or model quality — is typically the primary deployment barrier in industrial robotics.

Automotive partners are showing particular interest because the technology they developed for vehicles — safety-certified compute, real-time sensor fusion, ASIL-compliant fault management — maps directly to robotics requirements. Arm's Cortex-based CPUs appear in systems from Tesla, Rivian, NIO, Mercedes-Benz, Honda, and Geely, giving the company a baseline of certified partners that other physical AI ecosystem efforts lack.

Read more: Robot tactile sensing hits its industrial inflection in 2026

The Milestones That Determine Whether This Succeeds

O'Driscoll is scheduled to present at RoboBusiness 2026 in Santa Clara on October 20 and 21. Whether buyers, standards bodies, and insurers begin using the RL taxonomy in procurement specifications is the most consequential near-term signal for the framework's adoption: SAE's autonomy levels gained industry traction precisely because enough parties started using them consistently in regulatory filings and vehicle purchase contracts, creating a self-reinforcing reference standard.

The conformance gap is the program's most significant technical risk. A capability taxonomy without an external verification path creates conditions where vendors self-certify at ambitious levels, generating the same definitional chaos the RCF was designed to eliminate. Arm's stated commitment to industry co-development is the correct response to this problem, but the framework's practical value scales directly with how quickly an independent conformance infrastructure materializes.

The NVIDIA-Hugging Face acquisition's regulatory outcome in the first half of 2027 will also shape the ecosystem's composition. Arm's physical AI strategy depends on offering a broadly available, compute-neutral alternative to NVIDIA's vertically integrated stack. A genuinely open Hugging Face makes that alternative stronger; a tightly coupled NVIDIA-Hugging Face would push the gap between the two ecosystems wider and force Arm's partners to resolve whose model distribution infrastructure they depend on.