Trusted Robots Need a Trusted Software Foundation
Robotics is rapidly moving from controlled laboratories and fenced industrial environments into public spaces, factories, healthcare facilities, commercial venues, and homes. The transition from technical demonstration to dependable deployment, however, introduces a fundamentally different engineering challenge: robots must remain safe, deterministic, and predictable when operating in environments that are neither controlled nor fully observable.
WAIC 2026 highlighted this transition. Robotics and embodied AI were among the event’s most closely watched domains, with more than 200 companies showcasing deployments across manufacturing, services, and other application areas. Dozens of embodied AI robots also performed tasks such as navigation, guidance, and visitor reception throughout the venue.
These demonstrations illustrate how quickly robotics capabilities are advancing. They do not, however, answer the harder question: Can a robot continue to behave safely and predictably when its environment changes unexpectedly?
Recent robot incidents demonstrate why that distinction matters. Failures involving public demonstrations, entertainment robots, and industrial robotic systems have resulted in collisions, injuries, and legal disputes. Such events are not simply isolated demonstrations gone wrong. They expose a broader engineering problem: the software foundations supporting increasingly autonomous robots must evolve as rapidly as their sensing, compute, and mechanical capabilities.
The robotics industry is therefore entering an important transition. Building a robot that can perform a task is one challenge. Building a robot that can perform that task reliably, deterministically, safely, and repeatably under unpredictable real-world conditions is another.
🤖 From Controlled Labs to the Complex Real World #
Modern robots increasingly operate outside environments where every variable can be anticipated.
A robot may need to interact with children and pets, respond to changing weather and lighting conditions, interpret unpredictable human behavior, navigate crowded environments, and transition dynamically between multiple tasks. At the same time, Physical AI is introducing increasingly sophisticated perception, reasoning, and autonomous decision-making capabilities.
This changes the fundamental requirements placed on the underlying software stack.
A successful laboratory demonstration can show that a robot is capable of completing a task under defined conditions. Production deployment requires demonstrating that the system can continue to behave safely when those conditions are violated.
The central engineering question is therefore:
When the environment changes, can the system still guarantee safe and predictable behavior?
The scale of this challenge is also increasing rapidly.
- ABI Research projects that the global robotics market will grow from approximately $50 billion today to $111 billion by 2030, with the worldwide installed base approaching 13 million robots.
- Goldman Sachs forecasts that the humanoid robotics market could reach $38 billion by 2035.
- Bank of America Institute projects that the number of humanoid robots deployed in daily applications worldwide could reach 3 billion by 2060.
As deployment scales, even low-probability software failures can become significant safety and operational risks.
The industry therefore cannot optimize solely for deployment speed or feature velocity. Scaling autonomous machines requires an infrastructure capable of maintaining predictable behavior as system complexity increases.
⚙️ Software Is Becoming the Robotics Bottleneck #
For much of robotics history, hardware capabilities dominated engineering discussions. Developers focused on improving motors, actuators, sensors, processors, batteries, and mechanical structures.
That balance is changing.
A survey of 1,000 robotics developers across multiple global markets, conducted by a third-party consulting firm commissioned by QNX, indicates that software architecture and system integration are becoming major constraints on robotics development.
According to the survey, 27% of developers identified software architecture and system integration as their largest performance bottleneck.
This represents an important shift in the robotics development stack. Higher-performance hardware does not automatically produce a safer or more reliable robot.
A modern autonomous robot may combine:
- Multiple sensors and perception pipelines
- Real-time control loops
- AI inference workloads
- Navigation and localization
- Motion planning
- Networking and cloud connectivity
- Security mechanisms
- Human-machine interfaces
- Safety monitoring
- Hardware abstraction layers
- Diagnostics and fault management
These components must coexist without allowing non-critical workloads to interfere with safety-critical functions.
As robots increasingly collaborate directly with humans, software infrastructure becomes part of the system’s safety envelope. A more powerful motor or more capable AI model cannot compensate for an operating system, scheduler, middleware layer, or integration architecture that behaves unpredictably under load.
For this reason, safety, reliability, determinism, and fault isolation need to be architectural properties rather than features added near the end of development.
🧠 The Gap Between Ideal Architecture and Deployment Reality #
The developer survey reveals a significant mismatch between what robotics engineers consider necessary and what many systems currently deploy.
Deterministic Real-Time Performance vs. General-Purpose Operating Systems #
Approximately 95% of respondents consider deterministic real-time performance important to the systems they build.
Yet 91% continue to use general-purpose operating systems for safety-critical tasks.
This creates an architectural tension.
General-purpose operating systems are designed to maximize flexibility, application compatibility, and overall system utilization. Safety-critical robotics workloads may instead require bounded latency, deterministic scheduling, controlled resource allocation, isolation, and predictable failure behavior.
The difference is particularly important when a robot simultaneously performs computationally intensive AI workloads and time-sensitive control operations.
A perception pipeline may tolerate additional milliseconds of latency. A safety-related control loop may not.
A robust robotics architecture therefore needs to distinguish between workloads according to their timing and safety requirements rather than treating the entire software stack as one homogeneous environment.
Increasing Autonomy vs. Limited Safety Confidence #
The same tension appears as robotics moves toward Physical AI.
According to the survey, 89% of developers expect AI robots with perception, reasoning, and autonomous action capabilities to become important to their company’s robotics strategy within the next three to five years.
However, only 29% reported high confidence that their systems can consistently make safe and predictable decisions in safety-critical scenarios.
The implication is significant: autonomy is advancing faster than confidence in the infrastructure required to constrain and validate that autonomy.
AI can determine what a robot should do. The underlying system architecture must still provide mechanisms that determine how safely, predictably, and reliably that decision can be executed.
🛡️ Safety and Compliance Are Architectural Requirements #
Software architecture is only one part of the challenge. Regulatory and certification requirements add another layer of complexity.
The survey found that 66% of developers experienced project delays associated with industry-specific certification requirements.
Cybersecurity and functional safety were among the most challenging compliance areas, with:
- 51% identifying ISO/SAE 21434 cybersecurity requirements as a major challenge.
- 49% identifying ISO 10218-related functional safety requirements as a major challenge.
These requirements are particularly difficult to address when safety and security considerations are introduced late in development.
Retrofitting certification into an architecture that was not designed for isolation, determinism, traceability, or controlled failure behavior can require substantial redesign.
The issue becomes even more serious under schedule and budget pressure. 84% of surveyed developers agreed or strongly agreed that project deadlines or budget constraints could cause developers to compromise on critical areas such as safety.
This creates a dangerous development dynamic: increasing market pressure encourages faster deployment precisely when increasing system complexity requires more disciplined engineering.
For autonomous robotics, safety cannot be treated as a final validation stage. It needs to influence operating-system selection, system partitioning, middleware architecture, resource management, diagnostics, update mechanisms, and development processes from the beginning.
⚖️ Who Bears Responsibility When Robots Fail? #
The complexity of modern robotics also makes responsibility increasingly distributed across the technology stack.
Survey respondents assigned responsibility for robot failures across multiple stakeholders:
- Manufacturers: 32%
- Software suppliers: 22%
- System integrators: 20%
- End users: 13%
- Regulatory bodies: 10%
At the same time, 69% of developers reported being somewhat or very concerned about potential legal liability resulting from robot glitches or malfunctions.
This concern reflects a broader reality: failures in autonomous systems rarely originate from a single component in isolation.
A robot’s behavior emerges from the interaction between hardware, firmware, operating systems, middleware, AI models, application logic, networking, sensors, actuators, and human operators.
That makes software architecture particularly important.
Clear separation of safety-critical and non-critical functions, controlled interfaces, fault containment, deterministic execution, comprehensive diagnostics, and traceable system behavior can reduce the likelihood that a failure in one subsystem propagates throughout the robot.
The software foundation is therefore not merely an implementation detail. It is part of the mechanism through which system-level responsibility and safety are engineered.
🔐 Trust Cannot Be Assumed—It Must Be Engineered #
It is tempting to evaluate robotics progress through increasingly impressive demonstrations: faster movement, more capable manipulation, larger AI models, better natural-language interaction, or increasingly human-like behavior.
But demonstrations measure capability under selected conditions.
Trust requires something more demanding.
A trusted robot must continue to operate within defined safety boundaries when conditions become unexpected, workloads become intense, components fail, and multiple software subsystems compete for resources.
That requires an architecture built around several foundational properties:
Determinism #
Safety-critical workloads require predictable timing behavior. Scheduling, interrupt handling, resource allocation, and communication paths must provide sufficient timing guarantees for the control system.
Isolation #
A failure or resource spike in an AI, networking, or application workload should not automatically compromise safety-critical functions.
Fault Containment #
The system needs mechanisms to detect failures and prevent them from propagating across software and hardware boundaries.
Reliability #
The platform must support continuous operation while providing robust recovery, diagnostics, and lifecycle management.
Verifiability #
Safety-critical behavior needs to be testable and auditable. Architecture, interfaces, execution behavior, and failure modes must be sufficiently controlled to support verification and certification.
Security #
As robots become connected and increasingly autonomous, cybersecurity becomes inseparable from functional safety. A compromised software component can ultimately become a physical safety issue.
These properties cannot be reliably added after an AI model or robotic application has already been built. They must be considered at the foundation of the platform.
🏗️ Building the Foundation for Physical AI #
The next phase of robotics will not be defined solely by better mechanical systems or larger AI models. It will depend on whether the software stack can provide a dependable execution environment for increasingly autonomous machines.
A modern robotics platform must reconcile two seemingly opposing requirements: sophisticated AI workloads need flexibility and computational scale, while safety-critical control functions need deterministic and constrained execution.
This makes architectural separation increasingly important.
The underlying platform should provide appropriate execution environments for different classes of workloads while maintaining controlled communication between them. AI inference, perception, navigation, application services, networking, and safety-critical control should not compete blindly for the same system resources.
A safety-oriented real-time foundation can provide the deterministic execution model required by control workloads while allowing higher-level software components to evolve independently.
This approach also improves the path toward certification. When safety-related functionality is isolated within an architecture designed for predictable execution and controlled interfaces, developers have a stronger foundation for demonstrating compliance and maintaining that compliance throughout the product lifecycle.
🚀 The Path from Robot Demonstrations to Trusted Deployment #
The robotics industry is approaching a decisive stage.
The challenge is no longer simply whether machines can perceive their surroundings, understand instructions, navigate environments, or manipulate physical objects. Increasingly, the question is whether they can perform those capabilities safely and predictably at scale.
The answer will depend heavily on the software beneath the AI.
As robots move into factories, streets, hospitals, commercial spaces, and homes, software infrastructure must provide the deterministic execution, isolation, reliability, security, and verifiability required for physical systems operating around people.
QNX’s foundational software portfolio addresses this layer of the robotics stack, with technologies designed around functional safety, real-time execution, security, and dependable embedded-system operation. Its safety-oriented foundation includes certification to the TÜV Rheinland ISO 26262 ASIL D functional-safety level and alignment with ISO/SAE 21434 cybersecurity requirements.
The broader lesson extends beyond any individual platform: trusted robotics begins with trusted foundation software.
If robots are expected to work alongside humans, trust cannot be established through demonstrations alone. It must be engineered into the system—from the operating system and middleware through application architecture, safety mechanisms, cybersecurity controls, and verification processes.
The future of robotics will ultimately depend not only on how intelligent machines become, but on how reliably their underlying software can turn that intelligence into safe, predictable physical behavior.