Software Is Now the Wall Robots Can't Scale

A survey of 1,000 robotics developers finds the industry's biggest obstacle isn't motors or sensors—it's the code holding everything together.

By The Robotics Desk

Walk through any advanced manufacturing facility today and you will find robots that can lift, sort, and navigate with mechanical precision. What you won't find, according to a new industry-wide survey, is software keeping pace. QNX's 'Inside the Robot: Architecture Benchmark Report'—drawn from 1,000 developers and engineers across the global robotics sector—lands a pointed conclusion: the hardware race is largely won; the software reckoning has barely begun. [1][2]

The numbers are stark. Almost one in three developers (27%) named software architecture and integration as their biggest performance bottleneck—compared with just 16% who pointed to hardware. [1] That gap, nearly two-to-one, signals a structural inversion in how the field thinks about progress. For decades, robotics was a problem of actuators, sensors, and processing power. Now the limiting factor is the invisible layer that ties those components together and tells them what to do when something unexpected happens.

This inversion matters because software failures in physical systems are not abstract. When code misbehaves in a data center, a server reboots. When it misbehaves in a robot sharing a hospital ward or a construction site with people, the consequences arrive in the physical world.

The survey, commissioned by QNX—a division of BlackBerry Ltd.—and conducted by OnePoll, found that more than four in five respondents (83%) said their systems are now operating alongside people. [1] Among organizations that have not yet deployed such systems, two-thirds (67%) expect to do so within three to five years. [1] The trajectory is clear: robots are leaving the controlled cage of the factory floor and entering the far messier geography of human life, from surgical suites to busy shop floors.

That migration raises the engineering stakes considerably. Nearly all respondents (95%) said deterministic, real-time execution is important to the systems they develop. [1][2] Determinism—the guarantee that a system will respond to any given input within a fixed, predictable window of time—is the foundational property of safety-critical software. It is what separates a robot arm that stops reliably when a human reaches into its path from one that stops most of the time.

Here is where the data turns uncomfortable. Despite that near-universal commitment to real-time behavior, 91% of respondents run their workloads at least in part on general-purpose operating systems (GPOS)—software architectures designed for flexibility and developer convenience, not for guaranteed timing. [1][2] As a result, 86% of those GPOS users said they are open to changing their OS. [1][2] They know the foundation is wrong. They have not yet replaced it.

There is a particular kind of tension that accumulates when an industry knows what it needs but cannot yet fully act on that knowledge. The gap is rarely about awareness—it is about the friction of transition, the cost of migration, the inertia of existing codebases and team skills.

[1] Each of those four is a software problem. None of them is solved by a faster processor.

Certification delays alone are reshaping commercial timelines. Two-thirds of respondents (66%) reported project delays because of certification processes, rising to about 70% in the U.K. and Germany. [1] In contrast, only 56% reported delays in China, where regulatory requirements are less stringent. [1] The compliance environment is effectively creating a geography of development speed: companies building in tighter regulatory regimes face longer runways to market, higher costs, and greater commercial risk—all traceable, in large part, to software that was not designed with certification in mind from the outset.

The specific standards causing the most friction are instructive. Cybersecurity standards such as ISO/SAE 21434 and functional safety standards like ISO 10218 were among the most challenging areas to comply with, cited by 51% and 49% of respondents respectively. [1] These are not obscure edge-case requirements. ISO 10218 governs the safety of industrial robots. ISO/SAE 21434 addresses road vehicle cybersecurity—increasingly relevant as robots gain connectivity and remote management capabilities. Struggling to meet them is not a niche problem; it is an industry-wide signal.

What the certification data really describes is a design debt problem. Systems built on architectures of convenience accumulate obligations that must eventually be paid—in engineering time, in delay, and sometimes in recall.

The investment intentions of development teams suggest the industry understands this, even if execution lags. Looking ahead, 85% of developers said they expect software to play an even greater role in robotics over the next three to five years. [1] Their biggest anticipated investments are AI-driven decision making and cybersecurity—both at 51%—followed by operating systems and real-time control software at 37%. [1] Security and determinism, the two properties most conspicuously absent from general-purpose stacks, now top the spending agenda.

The physical AI ambition layer sits above all of this. Almost nine in ten respondents (89%) said AI-enabled robots that can perceive, reason, and act autonomously in the physical world will be critical to their organizations' strategy over the next three to five years, with China leading globally. [1][2] Yet confidence in delivering that ambition safely is thin: only 29% of respondents felt 'very confident' in their ability to make safe, predictable decisions in real-world environments. [1] Ambition and readiness are not traveling at the same speed.

The report's most quietly alarming implication is not any single statistic but the pattern they form together. An industry in which 89% of developers consider physical AI essential to strategy, while 91% still run safety-critical workloads on software not designed for that purpose, and only 29% feel very confident in their ability to guarantee safe behavior—that is an industry whose ambitions and its infrastructure are seriously misaligned. [1][2] Software development now consumes more developer resources than hardware does. [1] The resources are there. The architectures to deploy them wisely are still catching up.

The optimistic reading is that this kind of gap, once named and measured, tends to close. Entire industries have rebuilt their foundations under pressure—automotive electronics being the most obvious precedent. Robotics is now at a similar inflection, where the pressure is regulatory, commercial, and physical all at once.

The robots are already in the ward, on the shop floor, navigating the street. The software that governs their judgment, their timing, and their response when something goes wrong has not finished catching up. That is not a prediction—it is what 1,000 developers just said, out loud, in data. [1][2]