Reliable Robotics: Bringing Certified Autonomy to Cargo Aviation

The cargo aviation market has a labor problem. The regional and express cargo networks that move freight across the United States depend on a supply of pilots willing to fly single-pilot or light twin operations on tight schedules, often into underserved airfields. That supply is contracting. The airlines have been siphoning pilots upward for years, and the regional cargo operators are feeling it acutely.

Reliable Robotics, founded in 2017 and headquartered in Mountain View, California, is pursuing a specific answer to this problem: certify autonomous flight systems for existing cargo aircraft under FAA regulations, and operate them commercially under Part 135. The company is not building a new aircraft. They are retrofitting autonomy onto certified airframes—starting with the Cessna 208 Caravan—and then seeking FAA approval to operate those aircraft without a pilot on board for cargo missions.

That is a harder problem than it sounds.

The Retrofit Certification Trap

There is a common assumption in aerospace startups that working with an existing certified airframe saves time. The airframe’s airworthiness baseline is already established. The structural, propulsion, and avionics certification history exists. You are not starting from zero.

That assumption is partially correct and mostly misleading.

When Reliable Robotics installs its autonomous flight system on a Cessna 208, they are modifying a Type Certificated aircraft. Under FAA regulations, any modification that may appreciably affect structural strength, flight characteristics, or other airworthiness qualities requires a Supplemental Type Certificate (STC). The STC process demands that Reliable demonstrate their modifications comply with the original certification basis of the aircraft—which for the 208 means Part 23 airworthiness standards—and that any new or modified systems meet applicable standards for their failure conditions.

Here is where the complexity compounds: the autonomous flight system Reliable is installing is not a passive avionics upgrade. It replaces the pilot as the entity responsible for operating the aircraft. The FAA’s existing regulations were written around the assumption of a human pilot in the loop. There is no existing certification pathway that says “here is how you certify a pilotless cargo aircraft.” Reliable is working with the FAA to establish that pathway in real time, which means the regulatory framework itself is a variable in their engineering process.

Simultaneously, operating the certified autonomous aircraft commercially requires a Part 135 Air Carrier Certificate. Part 135 governs the operational rules—crew requirements, dispatch procedures, maintenance programs, training standards, and more. Normally, an air carrier certificate is granted after the aircraft is certified. In Reliable’s case, the operational and airworthiness processes are running in parallel, each generating requirements that feed back into the other.

For a team that, by industry standards, is still small, the documentation and traceability burden this creates is significant.

ARP4754A: The System-Level Foundation

ARP4754A, published by SAE International, is the aerospace industry’s guideline for development of civil aircraft and systems. It is not a FAA regulation, but the FAA has accepted it as a means of compliance for showing that complex systems have been developed with appropriate rigor. For a company like Reliable, whose autonomous flight system is exactly the kind of complex, highly integrated system ARP4754A was designed to address, using this standard is not optional in any practical sense.

ARP4754A establishes a process framework built around two core ideas. First, that safety requirements must be allocated from the aircraft level down through systems, subsystems, and components in a structured, traceable way. Second, that the rigor of development—the depth of review, testing, analysis, and verification—must be commensurate with the consequences of failure.

For the autonomous flight system, this means Reliable must conduct a Functional Hazard Assessment (FHA) at the aircraft level, identifying every function the autonomous system performs and what happens when each function fails. Those failure conditions are then classified by severity—catastrophic, hazardous, major, minor—and assigned quantitative safety objectives. A catastrophic failure condition, one that would result in loss of the aircraft and its occupants or persons on the ground, must be shown to have a probability of less than 1×10⁻⁹ per flight hour.

The FHA feeds a System Safety Assessment (SSA) and a Fault Tree Analysis (FTA) or Dependence Diagram, which together build the safety case from the top level down to the component level. Every requirement generated by this process must be traceable. When the FAA asks “show me how your loss-of-communication failure mode cannot result in a catastrophic outcome,” the answer has to be documented, traceable, and verifiable.

For a retrofit autonomous system, the FHA is particularly challenging because the failure modes of the autonomous system interact with the existing aircraft systems in ways that the original certification basis did not anticipate. A Cessna 208 was certified with a human pilot as the assumed means of detecting and responding to anomalies. When you remove that assumption, every function the pilot implicitly performed—monitoring engine parameters, detecting icing conditions, making go/no-go decisions—becomes a function that must be explicitly allocated and verified in the modified system.

DO-178C: Where the Software Reality Lives

ARP4754A handles the system level. DO-178C, the Software Considerations in Airborne Systems and Equipment Certification standard, handles the software. For Reliable’s autonomous flight system, which is fundamentally a software-intensive system making real-time flight decisions, DO-178C is where the detailed work happens.

DO-178C defines five software levels, A through E, based on the severity of the failure condition that a software error could cause. Level A software, where a failure could contribute to a catastrophic failure condition, carries the heaviest development and verification requirements: full MC/DC (Modified Condition/Decision Coverage) testing, formal design reviews, independence requirements between development and verification, and complete traceability from high-level requirements through low-level requirements to source code to object code to test cases.

For an autonomous flight system where certain software functions directly control the aircraft’s flight path, significant portions of the codebase will be Level A or Level B. That means the traceability chain from the system-level safety requirements through the software requirements, the software architecture, the detailed design, the code, and the test results must be complete, bidirectional, and verifiable. Every software requirement must trace to at least one test case. Every test case must trace back to a requirement. And the system-level safety objectives—the ones derived from the ARP4754A FHA—must trace into the software requirements that implement them.

This is not a documentation exercise you can backfill. The standards require that the traceability be established and maintained throughout the development lifecycle, not reconstructed at certification time. Teams that treat requirements management as a paperwork task at the end of development do not pass DO-178C audits.

The Small Team Problem

This is where Reliable Robotics faces a challenge that is structural, not just technical. Established primes—Honeywell, Garmin, Collins Aerospace—have large systems safety and certification teams with decades of institutional knowledge. They have dedicated DER (Designated Engineering Representative) staff, established tool qualification processes, and the internal bandwidth to run parallel workstreams across FHA, SSA, software development, and verification.

Reliable is doing this work with a fraction of the headcount. The advantage is speed and coherence—a smaller team can make faster decisions and maintain tighter alignment across disciplines. The disadvantage is that the documentation and traceability burden does not scale down with the team. The FAA does not require fewer requirements artifacts because you have fewer engineers. The safety case must be equally complete regardless of organizational size.

This creates pressure to find ways to maintain certification-grade rigor without the overhead of large-team processes built for large teams. Legacy requirements management tools—IBM DOORS, Polarion, Codebeamer—were designed in an era when requirements management meant controlled documents and change boards. They are powerful in the hands of teams trained to use them, but their overhead is significant. Configuration, administration, and the manual effort required to maintain bidirectional traceability across large requirement sets can consume engineering time that a small team cannot spare.

There is also a structural issue with document-centric tools when applied to the kind of multi-framework traceability Reliable must manage. The relationships between Part 23 airworthiness requirements, ARP4754A system-level requirements, DO-178C software requirements, and Part 135 operational requirements are not linear. They form a graph. A single operational requirement—“the aircraft shall maintain instrument meteorological conditions capability”—generates implications in the airworthiness domain (sensor requirements, failure modes), the software domain (algorithm requirements, coverage requirements), and the operational domain (dispatch criteria, maintenance intervals). Tracking those relationships in a flat document or a table-based RTM is technically possible. It is also fragile and expensive to maintain.

Tools built around graph-based requirement models handle this more naturally. Flow Engineering, designed specifically for hardware and systems engineering teams operating under formal standards, represents this approach. Its architecture treats requirements, tests, design artifacts, and standards references as nodes in a connected graph rather than rows in a spreadsheet. For a team managing simultaneous Part 23 and Part 135 compliance with ARP4754A and DO-178C threading through both, the ability to query “what Part 135 operational requirements have incomplete traceability to verified software requirements” as a live question—rather than a manual audit task—is not a convenience feature. It is how a small team stays on top of a large compliance problem without hiring a compliance department.

Flow Engineering’s focus on systems and hardware teams also means it does not try to be a general-purpose project management tool. That deliberate scope means it integrates with the development artifacts that matter—model-based design outputs, test management systems, configuration management—rather than being a document repository with a requirements module bolted on.

What the Certification Pathway Actually Looks Like

Reliable Robotics has been public about pursuing an FAA Special Federal Aviation Regulation (SFAR) as part of their certification approach, which allows the agency to establish tailored rules for operations that fall outside existing regulatory categories. This is not an unusual path for novel technologies—it is how the FAA has handled other significant departures from conventional operations—but it does mean Reliable is partly in the business of writing the regulatory framework they will be certified under.

That has an important engineering implication: requirements derived from regulations that are still being negotiated are volatile. A requirements management process that cannot handle requirement volatility gracefully—tracking changes, propagating impact assessments, maintaining traceability through revisions—will accumulate technical debt at every regulatory update. For Reliable, where the regulatory dialogue with the FAA is ongoing, this is not an edge case. It is the normal operating condition.

The company has completed multiple FAA-observed flight demonstrations of the Cessna 208 operating without a pilot, and has been accumulating flight data to support the safety case. The path to commercial operations under Part 135 still involves sustained engagement with the FAA on operational procedures, maintenance programs, and the acceptable means of compliance for the autonomous system. It is a multi-year process, not a one-time certification event.

An Honest Assessment

Reliable Robotics is doing technically serious work on a problem that matters. The cargo aviation labor shortage is real, the regulatory pathway they are pursuing is credible, and their decision to start with an existing certified airframe—despite the STC complexity—reflects a pragmatic assessment of what is achievable in the near term.

The risks are equally real. Regulatory timelines in aerospace are not controllable by the applicant. The FAA’s capacity to engage with novel certification requests is finite, and the agency’s institutional risk tolerance for pilotless commercial cargo operations over populated areas will be tested continuously. The company’s burn rate against a multi-year certification timeline is a business risk that sits entirely outside the engineering domain.

What is not in question is that the engineering approach is grounded. Using ARP4754A and DO-178C as the backbone of a safety argument for an autonomous system is the right framework, not because it is required, but because those standards exist precisely to make safety arguments legible and verifiable. Small teams that find ways to do rigorous requirements management without bureaucratic overhead—through better tooling, tighter process design, or both—are the ones that can make that framework work at startup velocity.

Whether Reliable Robotics reaches commercial operations first, or whether a competitor or regulatory change reshapes the market, the engineering discipline they are developing is the template the industry will use for the next decade of autonomous aviation certification.