In my last post I wrote about Arm Total Design for Physical AI and the Robotics Capability Framework. This time I want to go one layer down, into the part I find most interesting: the order of work. How do you get from a robot prototype on a bench to a robot you can deploy, update, and trust across a fleet?
Arm’s answer is a pipeline. Software starts on a virtual copy of the chip, gets tested inside a simulated machine, lands on a stack whose layers have already met each other, and keeps getting updated long after the first unit ships. Arm puts it this way on its program page: “Leveraging digital twins, hardware and software virtual platforms with ISA parity enables physical AI development to start earlier with CI/CD through the lifecycle of a system.”
Roughly 83 partners appear on that page, and they spread across every stage of the pipeline. So let me walk through it stage by stage, looking at what slows robotics teams down today and who is showing up to help.
Stage one: start the software before the silicon
Anyone who has shipped hardware knows the waiting game. The software team is ready, the boards are not, and when the boards do arrive, the firmware and driver bugs arrive with them. Months disappear into bring-up.
Virtual platforms are meant to close that gap. A virtual model of the target chip runs your real firmware, operating system, and middleware binaries. Because cloud instances on AWS or Alibaba Cloud are also Arm based, the same toolchain and the same binaries work in the cloud and on the device. Arm calls this ISA parity, and it means you can run continuous integration against a chip that does not exist yet.
The electronic design tool vendors are here in force. Synopsys said on September 9 that it is extending its virtual development kits, electronics digital twins, and hybrid setups with hardware-assisted verification from cars to physical AI platforms. Siemens EDA says that running virtual platforms natively on Arm infrastructure helps developers “identify defects months before first silicon.” Cadence, Corellium, and Lauterbach sit on the partner wall too.
Firmware is part of this story. Insyde brings up boot firmware on Arm virtual platform models “so software and silicon work can proceed in parallel rather than in sequence.” Its CTO, Tim Lewis, describes that as how Insyde helps customers “shift-left timelines, allowing them to focus on real product differentiation.”
Stage two: test the whole machine in simulation
A chip on its own does very little. A robot is a chip wired to sensors, motors, networks, and a messy world. The second stage connects the virtual chip to a model of the rest of the machine and a simulated environment, then runs the whole system in cloud CI with repeatable scenarios.
Here I want to be careful. The one worked example Arm cites comes from automotive. Arm, AWS, Google, HERE, RemotiveLabs, and Siemens built a digital cockpit reference that let developers test software on Arm’s Zena automotive platform before silicon existed. Arm’s developer blog walks through the mechanics: virtual platforms, a software model of the vehicle’s wiring, environmental simulation, and every CI build deployed to the virtual platform.
That is a useful template for robots. It is still a template. I have not seen a published sim-to-real flow for robots under Total Design, and I have not seen measured time savings for robot programs. For robotics, this stage is the thinnest part of the story today, which also makes it the most interesting one to watch.
Stage three: a stack whose layers already know each other
Ask a robotics team where the time goes and you will often hear the same answer: integration. Firmware, a real-time OS, safety layers, middleware, perception, models, and cloud services all come from different suppliers, and each program re-validates them against each other. Synopsys puts it plainly: “Pre-integrated, pre-validated solutions for physical AI remain limited, increasing development complexity and risk.”
Total Design gathers suppliers for each layer in one place. On the operating system and middleware side you find QNX, Green Hills, Elektrobit, ETAS, Red Hat, and the Autoware Foundation. Models come from Hugging Face, Liquid AI, and ModelBest. Silicon partners include NXP, ST, and Samsung. Robot makers such as Unitree, Deep Robotics, and Bear Robotics are part of the circle too.
STRADVISION’s Philip Vidal captured why this layer matters: “The hard part of physical AI is no longer whether a model can perceive something. It is whether that capability can be specified, integrated and shipped inside real constraints.”
A partner program is a starting point for that integration work. Membership on its own does not guarantee that two listed products interoperate, and for several headline members I have not yet seen a public, program-specific deliverable such as a reference stack or validated image. That work is still ahead.
Stage four: deployment and the long tail of updates
Shipping the first robot is the beginning. Unit ten thousand needs to run what unit one was validated on, and the whole fleet needs updates, rollback, and visibility for years.
Peridio joined Total Design on September 10 with its embedded Linux and fleet management layer. It says teams usually spend “12 to 18 months and a dedicated platform team” building this infrastructure themselves. CTO Justin Schneck describes the goal as an operating system that “travels with the application,” so “hardware enablement becomes configuration instead of a rewrite.” Insyde, eSync Alliance, and Excelfore also appear on the partner wall for firmware and over-the-air updates.
Where the Capability Framework fits
The Robotics Capability Framework slots into this pipeline as a way to set requirements. You pick a target level for each capability up front, and that level shapes your compute, latency, and determinism budgets for the virtual platform, the scenarios you test in simulation, the safety layers in your stack, and how you govern updates in the field. The framework is Issue 1.0, it is still evolving, and it explicitly does not define a certification program. Treat it as shared vocabulary for your requirements.
Reading it honestly
I am encouraged by this pipeline, and I also want to keep it in proportion. The strongest proof is automotive. Robot-specific results are still mostly announcements, and Arm told The Robot Report it plans to start running sessions with members “in the coming months.” The time-savings figures above come from Arm and its partners, not independent measurement.
ISA parity is also worth thinking about with open eyes. It is a real engineering gain to run the same binaries in the cloud, in simulation, and on the device. It is also a pull toward one architecture across your whole pipeline. That can be a perfectly good choice. Just make it a deliberate one.
What I would do next as a builder
Start by running your perception and control CI on Arm cloud instances, such as AWS Graviton. Everything else in this pipeline builds on that, and you can do it this week.
Then ask Synopsys, Siemens EDA, or Cadence about a virtual or hybrid model for the chip class you are considering, and bring your firmware and OS image to it before you commit to a board.
Design over-the-air updates and rollback from day one. Look at a fleet layer like Peridio so a silicon change later feels like a configuration change.
Finally, write a capability profile using the Robotics Capability Framework. Set a target level for each capability and let it drive your latency, determinism, and update requirements.
None of this needs to wait for the robotics references to mature. The tools for the first stage exist now, and the teams that practice the pipeline early will be the ones ready when the robot-specific pieces land.