BlackBerry QNX is putting a sharper point on a trend robotics engineers have been seeing for a while: the hardest problems are no longer in the mechanics.
In its Inside the Robot: Architecture Benchmark Report, the company says 27% of developers now identify software architecture and integration as the biggest bottleneck in robotics innovation. Only 16% name hardware. That gap matters because it signals a change in where progress is getting stuck. The constraint is moving up the stack, from actuators and chassis to the software layers that decide, coordinate, secure, and certify behavior.
That shift is especially visible as robots leave controlled demos and move into dynamic real-world deployments. A system that works in a lab or behind a safety perimeter can fail once it has to share space with people, process unstructured inputs, and cope with variable conditions on a factory floor, in a warehouse, or on city streets. In that setting, the limiting factor is often not whether the robot can move, but whether the software can make reliable decisions fast enough, recover from faults, and remain predictable under mixed workloads.
QNX’s framing is consistent with that reality. The report points to AI decision-making, cybersecurity, and a robust OS/RTOS as the main software concerns now shaping robotics architecture. That triad is telling. AI decision-making has to handle perception-to-action loops without introducing opaque failure modes. Cybersecurity has to account for robots that are networked, remotely managed, and increasingly integrated into enterprise systems. And the operating system or real-time operating system has to provide deterministic behavior across components with different criticality levels, from inference and planning to safety monitoring and motion control.
That last piece is easy to underestimate. In robotics, OS/RTOS design is not just an infrastructure detail; it is the layer that determines whether the system can meet timing guarantees, isolate faults, and integrate safety-critical functions without turning the software stack into a brittle tangle. As more robots run AI-heavy workflows alongside control loops that cannot miss deadlines, mixed-criticality scheduling and predictable latency become product requirements, not architecture preferences.
For vendors, the implication is that roadmaps built around spec-sheet gains will not be enough. Better payload, longer battery life, or more capable sensors still matter, but they are no longer the primary differentiators once a robot is expected to operate in a shared environment. Platform maturity, secure software foundations, and cross-subsystem integration are becoming the features that determine whether a robot can actually be deployed at scale.
That also changes how partnerships and ecosystems are judged. In a hardware-first era, a robotics company could stand out by shipping a better arm, a better drive system, or a better sensor suite. In a software-first era, the more durable advantage comes from how well the platform integrates perception, planning, control, safety, and security across the stack. The companies that can simplify certification, reduce integration friction, and offer a predictable OS/RTOS substrate are likely to be better positioned when buyers evaluate deployment risk.
The market signal here is subtle but important: cybersecurity and OS/RTOS reliability are increasingly deployment prerequisites. Buyers are not just asking whether the robot performs in a benchmark environment; they are asking whether it can be trusted in a mixed, human-shared operational setting, whether it can be updated safely, and whether failures can be contained without cascading into downtime or safety incidents.
For engineering teams, the practical response is to treat software architecture as a first-class product constraint. Modular software designs make it easier to swap perception models, control policies, and communications layers without destabilizing the system. Verifiable CI pipelines help catch regressions in integration, timing, and safety behavior before they reach the field. And safety-certified software stacks can shorten procurement cycles by reducing the amount of custom validation each customer has to perform.
Investors should watch for the same signals in a different form. The most interesting robotics platforms are likely to be the ones that can show repeatable integration velocity, not just impressive prototypes. Metrics around software reliability, real-time performance, fault isolation, secure update mechanisms, and certification readiness may tell you more about near-term commercialization than headline hardware capabilities.
The broader message from the QNX report is not that hardware no longer matters. It is that hardware progress is no longer enough to carry the industry forward on its own. As robotics moves into more unpredictable environments, software architecture becomes the gatekeeper for deployment. The winners in the next few quarters are likely to be the companies that build for that reality from the start.
