IN Brief:
- Arm Total Design for Physical AI brings together more than 80 companies across compute, software, AI models, sensing, simulation, and robotics.
- The Robotics Capability Framework progresses from RL0 reactive systems to RL5 self-improving machines.
- Capability levels are intended to connect robot behaviour with latency, compute placement, memory, power, determinism, and safety requirements.
Arm has extended its Total Design ecosystem into physical AI and introduced a Robotics Capability Framework intended to give developers, integrators, and users a shared language for increasingly capable autonomous machines. More than 80 organisations are participating across compute hardware, software, AI models, sensors, virtual platforms, digital twins, and robotic systems.
The announcement is primarily an integration and system-definition initiative rather than a new processor launch. Autonomous vehicles and robots combine perception, AI inference, real-time control, communications, safety functions, and actuation, with each subsystem operating under different timing, power, and reliability constraints. Arm is trying to bring more of the companies behind those layers into a common development model before individual systems reach hardware integration.
Total Design has previously been used around cloud infrastructure, where semiconductor IP, foundries, EDA tools, firmware, packaging, and software have to converge around a processor platform. The physical-AI extension broadens the model to include technologies such as sensing, robotics software, AI models, virtual development platforms, and digital twins.
One of the programme’s first initiatives is the Robotics Capability Framework. Its proposed scale runs from RL0 reactive systems to RL5 self-improving machines, creating six levels intended to describe increasing behavioural and system sophistication rather than relying on broad terms such as intelligent, autonomous, or AI-enabled.
The useful part for electronics engineers sits underneath those labels. Arm says the framework will connect real-world behaviour and output with system requirements including latency, compute placement, memory, power constraints, determinism, and safety. A machine capable of more complex perception and reasoning may consequently require a different balance between local processing, memory bandwidth, communications, and deterministic control rather than simply a larger AI model.
That distinction matters because physical systems cannot treat every workload like conventional application software. A cloud response arriving a second late may be inconvenient in an office application; a delayed motion-control or obstacle-avoidance response can make a machine unusable. Robotics also mixes workloads operating at different timescales, from image processing and path planning to sensor acquisition and motor control.
The framework is still being developed and should not be treated as a formal industry standard. Arm describes it as a starting point informed by companies across the robotics ecosystem and is inviting further participation. The initial structure therefore provides terminology for discussion rather than a certification scheme or mandatory hardware architecture.
There is a parallel with existing work on interfaces. MIPI Alliance has separately begun examining physical-AI interface requirements for humanoid and embodied systems, including hardware and software architecture and possible specification extensions. Both initiatives reflect the same underlying problem: robotics platforms are becoming too complex for every supplier to define its own assumptions about data movement, compute placement, and system capability.
Arm points to an automotive digital-cockpit collaboration involving AWS, Google, HERE, RemotiveLabs, and Siemens as an example of the broader Total Design approach. That project allowed software to be developed and validated on Arm Zena CSS before production silicon was available, illustrating how virtual development can move software work earlier in the hardware cycle.
The same principle is relevant to robotics because mechanical systems, sensors, compute modules, and actuators may all arrive on different schedules. Virtual platforms and digital twins can allow software teams to work against a representative architecture while the finished machine is still being developed, although eventual timing and safety behaviour still have to be verified on physical hardware.
The more than 80 participants named by Arm include companies working across semiconductors, operating systems, AI models, cloud platforms, software tools, and finished robots. Their participation does not create an interoperable robotics stack by itself. The practical value will depend on whether the programme produces interfaces, requirements, and development artefacts that reduce repeated engineering work between suppliers.
For design teams, the capability framework will be useful only if its levels translate into measurable system constraints. Robotics already has enough loose terminology. Connecting a claimed capability to processor performance, memory, sensor bandwidth, latency, power, real-time behaviour, and safety requirements would give engineers something more useful than another label to put on a demonstration machine.
