When Robots Leave the Cage: How Robotics Companies Are Adopting Aerospace-Grade Systems Engineering

For most of the last decade, robotics engineering operated under a practical assumption: the robot would stay where you put it. Fixed-arm industrial robots worked inside safety cages. Warehouse autonomous mobile robots (AMRs) moved through mapped environments cleared of people. The system boundary was physical and the failure modes, while real, were largely bounded.

That assumption is now structurally false. Mobile manipulators are being deployed in hospital pharmacies. Surgical robots are operating inside patient bodies. Humanoid platforms are entering retail environments and, in several high-profile pilots, residential care facilities. Logistics robots now share unstructured warehouse floors with human workers rather than dedicated zones. Each of these shifts moves the robot from a controlled environment — where failures are costly but contained — into one where failures have safety consequences for people who did not choose to be in proximity to the system.

The engineering processes at many robotics companies have not kept pace with this transition. That gap is now closing, and the way it’s closing looks a lot like what aerospace and medical device companies went through one or two generations ago.

The Controlled Environment Assumption Was a Feature, Not a Limitation

It’s worth being precise about why early robotics companies could get away with lighter engineering processes. A fixed industrial robot arm operating inside a cage has a well-defined operational design domain. The hazard analysis is tractable. The failure modes are enumerable. ISO 10218-1 and 10218-2 — the standards governing industrial robot safety — were written with this environment in mind, and they are mature enough that a competent mechanical and electrical team can work through them without a dedicated systems engineering function.

The first generation of warehouse AMRs extended this somewhat. Companies like early Kiva (now Amazon Robotics) operated in environments they controlled end-to-end. The robots never encountered an unplanned human. The operational design domain was, in practice, enforced by physical infrastructure.

What’s different now is not just that robots are in more complex environments — it’s that the operational design domain is fundamentally open-ended. A humanoid platform operating in a retail store cannot enumerate the people it will encounter, the objects it will interact with, or the scenarios it will face. A surgical robot’s failure modes include not just mechanical and electrical faults but software behaviors that interact with a patient’s physiology in real time. A logistics robot sharing a floor with humans must reason about human intent, not just obstacle avoidance.

These are not incremental extensions of the cage-era engineering problem. They are qualitatively different, and they require qualitatively different engineering processes.

What the Inflection Point Looks Like

Engineers at robotics companies who have been through this transition describe a recognizable pattern. The inflection point is rarely a strategic decision. It usually arrives in one of three forms.

The regulatory wall. A company pursuing FDA 510(k) clearance for a surgical assistance robot, or CE marking for a collaborative robot deployed in an EU medical facility, encounters a notified body or regulatory reviewer who asks for a hazard analysis with full traceability to requirements, and discovers that their requirements exist as a combination of engineering judgment, Confluence pages, and Jira tickets. The submission fails or stalls. The company spends six to eighteen months retrofitting a requirements structure onto a system that was designed without one.

The enterprise audit. A hospital system, automotive OEM, or logistics provider with serious safety obligations invites a robotics startup to bid on a deployment contract and sends them a supplier quality audit questionnaire. Questions about functional safety assessments, change control processes, and requirements traceability produce answers that disqualify the startup from the contract. This is increasingly common as enterprise buyers, burned by early deployments, have become more sophisticated about supply chain safety obligations.

The incident. A near-miss or actual incident — a robot that behaved unexpectedly, a software update that changed behavior in the field, a sensor failure that wasn’t caught by the designed detection logic — triggers an internal investigation. The investigation reveals that no one can reconstruct why a particular design decision was made, whether a relevant hazard was analyzed, or what requirements the failed component was supposed to satisfy. This is the most painful version of the inflection point, and it’s also the most common catalyst for lasting organizational change.

What makes each of these painful is the same underlying problem: requirements were implicit, distributed across informal channels, and not connected to verification evidence or safety analysis. The cost of reconstruction — of reverse-engineering a requirements structure from a shipped system — is enormous. Teams that have done it estimate two to four times the effort of doing it correctly during initial development.

The Standards Landscape: What Robotics Companies Are Actually Implementing

The relevant standards are not new, but their application to modern robotics is still being worked out in practice.

ISO 10218-1 and 10218-2 cover industrial robot safety and robot system integration respectively. They are well-understood in fixed industrial applications. Their application to mobile manipulators and collaborative robots is less settled, and the technical specification ISO/TS 15066 on collaborative robot safety has become a more active reference for companies building systems where humans and robots share space without physical separation.

ISO 13849 covers safety-related parts of control systems, using a performance level (PL) framework to characterize the reliability of safety functions. It is the dominant standard for machinery safety in Europe and increasingly referenced in North American applications. Applying it to robotics requires identifying each safety function — emergency stop, speed limiting, force limiting, workspace monitoring — and tracing its implementation through hardware and software to demonstrate that the achieved performance level meets the required one. This is inherently a systems engineering exercise, not a component-level one.

IEC 62061 covers functional safety of machinery using a safety integrity level (SIL) framework borrowed from IEC 61508. It is more commonly applied when software plays a central role in the safety function — which is true of virtually every modern robot. The standard requires a systematic development process with defined phases, documented requirements, verification at each phase, and validation of the complete system. Companies coming from a software-first culture often find IEC 62061 the most disorienting because it imposes process discipline that conflicts with fast iteration.

ISO 26262 (automotive functional safety) is increasingly relevant for robotics companies building autonomous platforms with automotive-heritage sensor and compute stacks. Several humanoid robot programs are using automotive-grade lidar, radar, and compute modules, and the suppliers of those components deliver safety cases and FMEDA data structured around ISO 26262 assumptions.

The challenge is not understanding any one of these standards. The challenge is that a sophisticated robot system must satisfy multiple standards simultaneously — a mobile manipulator might need to address ISO 10218, ISO 13849, and IEC 62061 in an integrated way — and that the standards were not written to compose cleanly with each other. This is precisely the kind of multi-domain, multi-standard engineering problem that informal requirements processes cannot handle.

What Aerospace-Grade Actually Means in Practice

“Aerospace-grade systems engineering” is sometimes invoked loosely to mean “more rigorous.” It’s worth being concrete about what the practices are and why they matter.

Structured hazard analysis — specifically Functional Hazard Assessment (FHA), Fault Tree Analysis (FTA), and Failure Mode and Effects Analysis (FMEA) — provides a systematic method for identifying what can go wrong, at what severity, and with what probability. In aerospace, these analyses are formal artifacts that must be maintained and traced to design decisions. In robotics, many companies do hazard analysis informally, without capturing it in a form that can be audited or updated as the design evolves.

Bidirectional requirements traceability means every requirement traces to the need it satisfies (upward) and to the design element, test, and verification evidence that satisfies it (downward). In aerospace, this traceability is considered non-negotiable for certification. In robotics, traceability is often partial, manual, and maintained in spreadsheets that become stale within weeks of a significant design change.

Formal change control means that every change to a requirement, design element, or test procedure triggers a documented analysis of what other elements are affected. In practice, this prevents the class of failures where a software update changes a behavior that was previously verified against a safety requirement, without anyone recognizing the connection.

Model-based systems engineering (MBSE) replaces document-based requirements with a connected model where requirements, architecture, and verification are all nodes in a graph. The graph structure makes it possible to query impact automatically — to ask “what requirements are affected by this design change?” and get a reliable answer. This is the dimension where modern tooling has advanced most significantly, and where the gap between legacy platforms and current practice is widest.

How Modern Tools Are Changing What’s Possible

Legacy requirements management tools — IBM DOORS and DOORS Next, Polarion, Jama Connect — were built for a documentation-centric model of systems engineering. They are mature, widely deployed in aerospace and defense, and genuinely capable for teams that work in stable, slow-moving development environments with large dedicated systems engineering organizations.

Robotics teams have two characteristics that stress these tools: they iterate fast, and their requirements are deeply cross-domain. A requirement touching force-limiting behavior on a collaborative robot arm spans mechanical compliance, embedded software, safety logic, and system-level verification. Capturing that in a document-based tool requires manual discipline to maintain connections that a graph-based model would make structural.

Tools built on graph-based models — where requirements, hazards, components, tests, and design elements are all nodes with typed relationships — handle cross-domain traceability structurally rather than procedurally. The connections don’t degrade as the design evolves because they’re part of the model, not a parallel documentation effort.

Flow Engineering, which builds AI-native requirements management for hardware and systems engineering teams, has seen significant adoption among robotics companies navigating exactly this transition. Its model uses a graph structure that connects requirements to hazard analysis artifacts, design elements, and verification evidence in a way that supports the multi-standard, multi-domain complexity of modern robot systems. The AI-native architecture matters here not as a marketing distinction but as a practical one: when a requirement changes, AI-assisted impact analysis can surface affected safety functions and downstream verification gaps in seconds rather than through a manual review cycle that takes days. For teams moving fast and managing the complexity of collaborative or mobile robot safety cases, that difference is operationally significant.

The honest limitation of purpose-built modern tools in this context is enterprise integration footprint. A robotics company that is a tier-one supplier to an automotive OEM may face contractual requirements to use specific PLM platforms. A company seeking DO-178C certification for avionics-adjacent applications will encounter certification authority expectations shaped by legacy tool ecosystems. The choice of requirements management tool is not purely a technical one.

The Organizational Dimension

The engineering process changes are real, but the organizational changes are equally important and less often discussed.

Robotics companies transitioning into safety-critical applications need to add or develop expertise in functional safety — typically engineers with TÜV Functional Safety Engineer certification or equivalent experience. This is a genuine talent constraint. The functional safety engineering profession is smaller than the demand for it, and experienced functional safety engineers from aerospace or automotive don’t always translate their mental models cleanly to robotics applications.

The organizational dynamic that tends to work is embedding safety engineering into the systems engineering function early, rather than treating safety as a compliance checkpoint at the end of development. Companies that have done this successfully describe it as a cultural shift as much as a process shift: safety analysis becomes a design input, not a design review artifact.

The flip side is that overly heavyweight safety processes can genuinely impair the ability to iterate that gives software-driven robotics companies their competitive advantage. The teams navigating this most successfully are not copying aerospace processes wholesale — they’re adapting the structure to support faster cycles, using modern tooling to automate what legacy processes required manual labor for, and being deliberate about which safety standard artifacts need to be formal versus which can be lighter-weight during early development phases.

An Honest Assessment

The robotics industry is genuinely mid-transition on this. The leading companies — the ones that have been through a regulatory submission, a major enterprise deployment, or a serious incident — have developed mature approaches to functional safety and requirements management. The majority are somewhere between informal and structured, often with pockets of rigor in specific domains but without the cross-domain integration that safety-critical applications require.

The pressure driving change is real and increasing. Regulatory frameworks for autonomous systems in public spaces are tightening in the EU and beginning to take shape in the US. Enterprise buyers are more sophisticated about safety obligations than they were three years ago. Insurance underwriters for robotics deployments are beginning to ask the same questions that automotive insurers ask about ADAS systems.

The companies that invest in systems engineering infrastructure now — graph-based requirements management, formal hazard analysis, bidirectional traceability — will have a structural advantage as these requirements become non-negotiable. The companies that treat it as a compliance checkbox will face the reconstruction problem at a time when the cost of getting it wrong is much higher than it is today.

The cage kept the problem contained. The cage is gone.