Reliable Robotics: Certifying Autonomous Cargo Aircraft and the Systems Engineering Marathon Ahead

Reliable Robotics was founded in 2017 by Robert Rose and Juerg Frefel, both veterans of SpaceX’s flight software and systems teams. The company’s stated mission is practical and narrow: make cargo aviation safer and more economically viable by removing the single-pilot constraint from existing certified aircraft. Their current platform is the Cessna Caravan, a turboprop workhorse that moves freight for FedEx, Amazon Air, and regional carriers across thin-margin short-haul routes. The goal is not a clean-sheet autonomous aircraft. It is an autonomy system that can be installed on an existing certified airframe and approved by the FAA.

That distinction matters more than it might appear. It shapes every systems engineering decision the company makes.

The Certification Environment They Are Operating In

The FAA’s existing airworthiness framework was built around piloted aircraft. Part 23 (small aircraft) and Part 25 (transport category) define requirements for aircraft systems, but they assume a human pilot as the active safety monitor and decision-maker. When you remove that pilot — or demote them to a remote supervisory role — the compliance framework does not automatically transfer.

The FAA has been working on this problem. The MOSAIC rulemaking (Modernization of Special Airworthiness Certification) and the broader UAS integration effort have produced policy guidance, but not a complete certification framework for autonomous commercial cargo aircraft. What exists is a collaborative process: applicants like Reliable Robotics work with the FAA under an issue paper framework, jointly developing the means of compliance as the program progresses. The FAA issues special conditions for novel features, and each finding becomes part of the record that future applicants and regulators can reference.

This means Reliable Robotics is not just building an aircraft system. They are co-authoring the regulatory framework for a new category of aviation. That is a significant engineering and organizational commitment, and it is not fully separable from the technical work.

The Strategic Choice: Modify a Certified Platform

The decision to build on the Caravan rather than a clean-sheet design reflects a specific risk allocation strategy. The Caravan is certificated under FAA Type Certificate A37CE. Its airframe, powerplant, and primary aircraft systems already have approved designs and established failure modes. Reliable Robotics does not need to re-certify the wing or the PT6A turbine. They need to certify the autonomy system as a modification — a supplemental type certificate (STC) — and demonstrate that the modification does not adversely affect the existing type design.

This is a substantial simplification of the problem, but it introduces its own constraint: the autonomy stack must interface with systems it did not design, through avionics architectures it did not choose, on a platform that was not built with autonomy in mind.

The Caravan’s original avionics — typically a Garmin G1000 NXi in recent production variants — were designed for a seated pilot with hands on the controls. Control authority, mode logic, and failure annunciation were all designed around that human. Reliable Robotics must map their autonomy system onto those interfaces, understand every assumption baked into the original design, and ensure that the combined system — original aircraft plus autonomy stack — meets the applicable safety objectives.

That hardware-software interface is where a significant portion of the systems engineering work lives.

Managing the Hardware-Software Interface

When a new autonomy system connects to an existing certified avionics suite, the interface is not just a wiring harness or a data bus. It is a boundary between two systems with different design histories, different failure mode analyses, and potentially different assumptions about normal and abnormal operating conditions.

Reliable Robotics must characterize every signal they send to or receive from the original aircraft systems. For each interface, the relevant questions are: What does this signal mean under normal conditions? What does the original system do when this signal is absent, anomalous, or out-of-range? Does the original system’s response to an anomaly remain safe when a remote pilot rather than a seated pilot is the recovery resource?

This work requires detailed analysis of the Caravan’s original system safety assessment — documents that Textron Aviation holds under its type certificate. The STC process involves coordination with the original type certificate holder, which in practice means negotiating data access agreements and interface control documentation that the OEM may not have been under any prior obligation to maintain in the form an autonomy integrator needs.

The failure modes of the combined system are not simply the union of the failure modes of the two subsystems. Integration creates new failure paths. An autonomous flight management function that commands a heading change through the autopilot may interact with the autopilot’s own mode protection logic in ways neither system’s original designers anticipated. Identifying those interaction effects requires systematic analysis — functional hazard assessment, preliminary system safety assessment, and eventually a full system safety assessment — updated and re-validated as the design evolves.

This is not exotic work. It is rigorous, structured, and labor-intensive. It is the kind of work that does not accelerate easily.

Defining Safety Requirements for Autonomous Flight Functions

The safety requirements for a piloted aircraft have a conceptual anchor: the aircraft must be controllable, the pilot must be able to detect and recover from failures, and catastrophic failure conditions must be shown to be extremely improbable. The quantitative targets come from AC 23.1309 and similar advisory material.

For an autonomous system, the same targets apply — the FAA has been clear that autonomous aircraft must meet the same safety level as piloted aircraft. But the functional allocation has changed. The pilot’s contributions to safety — situation awareness, anomaly detection, manual recovery, go-around decisions — must now be allocated to some combination of the autonomy system, the remote pilot, and automated redundancy mechanisms.

Reliable Robotics must define, for each flight function and each hazard, what the autonomous system is responsible for detecting and how it responds, what the remote pilot is responsible for monitoring and authorizing, and what the aircraft’s own systems handle automatically without either. Each allocation must be traceable to a safety requirement. Each safety requirement must be validated against the top-level safety objectives. The resulting requirements hierarchy is the spine of the certification evidence package.

The challenge is that some of these allocations are genuinely novel. There is no prior compliance record showing that a remote pilot monitoring via datalink meets the human factors requirements that a seated pilot satisfies. Reliable Robotics must generate that evidence — latency measurements, workload assessments, link reliability analyses — and negotiate its acceptance with the FAA as a new means of compliance.

The Incremental Certification Strategy

Reliable Robotics has been explicit about their sequencing: they are pursuing remote pilot in command (RPIC) operations first, with a human pilot maintaining legal authority and monitoring responsibility from a ground station, before advancing to higher automation authority. This is not a capability limitation — it is a regulatory strategy.

The RPIC model is closer to existing FAA frameworks for unmanned systems and is therefore more tractable to certify near-term. It establishes an operational record. It generates data about how the autonomy system performs across actual flight conditions. And it builds an institutional relationship with the FAA that is itself a prerequisite for advancing toward higher autonomy.

Each increment of automation authority requires its own safety case. The remote pilot monitoring from a ground station with authority to intervene is a different safety architecture than a system that operates without a pilot on any segment. The second requires demonstrating that the automation can handle every scenario the pilot was previously relied upon to handle — including low-probability, high-consequence events that may not appear in a normal operational data record.

This is why the systems engineering discipline is the actual long-term constraint. The flight control algorithms can be improved continuously. The certification evidence — the documented hazard analyses, the verified requirements, the validation records, the means of compliance negotiations — must be built carefully, maintained as the design changes, and kept internally consistent. Inconsistency in the evidence package is not a documentation problem. It is a certification risk.

What the Market Requires and Why the Work Matters

The economic case for autonomous cargo aircraft on short-haul routes is straightforward. Single-pilot operations are the dominant cost driver on routes under 500 miles. Freight operators flying overnight small-package networks — the kind of routes where Caravans are common — operate on margins where pilot cost per flight is a significant line item. If autonomous operations can be certificated and insured, the unit economics improve materially.

The safety case is less obvious but equally important. The Caravan single-pilot environment is demanding. Fatigue, spatial disorientation, and controlled flight into terrain remain causes of fatal cargo accidents in exactly the operational environment Reliable Robotics is targeting. An autonomous system that meets or exceeds the safety record of single-pilot Caravan operations is not just commercially viable — it is arguably a safety improvement.

That argument, however, must be made quantitatively and formally to the FAA. It cannot be asserted. It must be demonstrated through the kind of structured safety analysis and documented evidence that constitutes a modern safety case.

The Honest Assessment

Reliable Robotics has done something harder than building an autonomous aircraft: they have built a serious systems engineering and regulatory engagement program around a genuinely novel problem, on a realistic platform, with a credible incremental strategy. The company has received an experimental airworthiness certificate and conducted hundreds of test flights. They have a commercial agreement with FedEx. They are far enough along that the remaining work is clearly visible — which is different from early-stage programs where the hard problems are still hidden.

The remaining work is substantial. The means of compliance for autonomous commercial cargo operations do not yet fully exist. The hardware-software interface documentation burden on an STC program is considerable. The safety requirements for autonomous flight functions in low-visibility and degraded-datalink scenarios are not yet fully negotiated with the FAA.

None of this is a fatal objection. It is an accurate characterization of where the program is in a multi-year certification marathon. The companies that finish that marathon first will not necessarily be the ones with the most sophisticated autonomy algorithms. They will be the ones that built the most rigorous, consistent, and defensible evidence package — and maintained it through every design change along the way.

That is a systems engineering competition as much as it is a technology competition. Reliable Robotics appears to understand this. Whether the organization can sustain that discipline over the years of work remaining is the question that matters most.