The eVTOL Certification Wave Is Rewriting How Aviation Does Systems Engineering

When the FAA issued its first special conditions for electric VTOL aircraft in 2022, it acknowledged something aviation regulators rarely admit openly: the rules weren’t written for this vehicle. Four years later, with Joby Aviation, Archer, Wisk, and the entities carrying forward Lilium’s technology all running active certification campaigns, the industry is generating regulatory precedent at a pace that traditional aerospace programs—measured in decades—have never approached.

The systems engineering implications are substantial and underappreciated outside the industry. These aren’t incremental certification exercises. They’re simultaneous, large-scale experiments in applying a certification framework—DO-178C for software, DO-254 for complex electronic hardware, ARP4754A for system development—to vehicle architectures that the authors of those standards did not anticipate.

What’s emerging from these programs is a body of practice that will shape aerospace systems engineering well beyond the eVTOL sector.

What Makes eVTOL Certification Structurally Different

The challenge isn’t any single novel element. It’s the combination.

A conventional rotorcraft achieves safety through mechanical redundancy and decades of failure mode data. A conventional fixed-wing transport achieves safety through structural margins, redundant hydraulics, and a regulatory framework refined across 70 years of accident investigation. eVTOL vehicles achieve safety through—in most architectures—distributed electric propulsion, highly redundant fly-by-wire control, and software and hardware that must perform functions that used to be mechanical.

That shift from mechanical to electronic/software implementation of safety-critical functions means that DO-178C and DO-254 compliance is not peripheral to eVTOL certification. It is the core of it. A vehicle like Joby’s S4 has more DAL-A software components than most regional jets. A vehicle like Wisk’s Cora—fully autonomous—has effectively no pilot backstop for software failure, which pushes the safety argument entirely into the system architecture and its verification.

The regulatory consequence: ARP4754A, which was written to guide system development for aircraft where some functions had mechanical fallbacks and pilots provided a final layer of mitigation, is being interpreted in real time for architectures where those assumptions don’t hold. The FAA has published multiple issue papers specifically addressing this interpretive gap. EASA has done the same under its SC-VTOL special condition framework. The resulting guidance is still evolving, which means programs are certifying against a moving target.

Requirements Management as Critical Path

In traditional aerospace, requirements management is acknowledged as important and practiced inconsistently. Cost and schedule pressure routinely produce programs where traceability is maintained in arrears—requirements captured, then linked to design artifacts and test cases after the fact, usually under pressure from a certification audit.

In eVTOL programs, that approach is failing visibly.

The reason is architectural coupling. A distributed propulsion system with eight or more independent motor controllers, each running DAL-A software, connected through a redundant flight control computer, monitored by a health management system that feeds pilot or autonomy stack displays, presents a requirements network of a different character than a conventional aircraft. Changes propagate differently. A modification to a failure detection threshold in a motor controller may affect the flight control system’s authority limits, which affects the aircraft-level safety assessment, which affects the certification basis, which affects other systems.

Multiple program managers across the industry have described this coupling as the factor that made requirements management a schedule-critical activity, not a compliance checkbox. When a change anywhere in the network requires manual identification of all downstream impacts—through static document links in a traditional RTM or through manual search across a requirements management database—the latency of that impact analysis becomes a program constraint.

The programs that have managed this most effectively share a common characteristic: they moved to graph-based requirements models early, before the architecture was stable. Graph-based traceability treats requirements, design elements, verification activities, and hazard analyses as nodes in a connected network rather than rows in a document. When a requirement changes, the affected downstream nodes are immediately visible. The question “what else does this touch?” has a computable answer rather than a human-research answer.

This is not a theoretical advantage at this scale. On programs where the graph isn’t maintained—where traceability lives in exported spreadsheets, in Word documents with manual cross-references, or in legacy tools that model requirements as hierarchical text with typed links—impact analysis on non-trivial changes is taking weeks. On programs with live, connected models, the same analysis takes hours.

What Certification Authorities Are Actually Doing

The FAA’s approach to eVTOL certification has been more adaptive than its reputation for conservatism would suggest. The G-1 issue papers issued for each program define the certification basis for that specific vehicle, and the positions taken in those papers—on topics like distributed propulsion failure independence, on autonomy system assurance, on the acceptable means of compliance for novel control architectures—are setting precedents that will apply to future programs.

Several positions are worth tracking for their systems engineering implications.

On software and hardware assurance levels: The FAA has generally resisted downgrading DAL assignments for functions that lack mechanical backup, even when applicants argued that system-level redundancy compensated for lower assurance at the component level. The practical consequence is that eVTOL programs carry a higher proportion of DAL-A and DAL-B software than comparable-complexity traditional aircraft. This directly increases the verification burden and makes requirements completeness more critical—DAL-A verification requires demonstrating that every requirement is tested, and every test traces to a requirement.

On failure independence: Distributed propulsion creates an argument that individual motor failures are independent events with bounded consequences—lose one motor, the others compensate. Certification authorities have scrutinized the independence claim carefully, requiring detailed common-cause analyses that examine shared power buses, shared control network messages, shared cooling systems, and shared software heritage between motor controllers. The systems engineering response has been to model these dependencies explicitly in the safety assessment, which requires that the safety model and the requirements model be connected—changes to either must propagate to the other.

On novel architectures lacking historical data: Traditional probabilistic safety assessment relies on failure rate data from operating experience. eVTOL propulsion systems don’t have that data. Certification authorities have accepted analysis-based safety cases with higher verification rigor as a substitute, but the analytical methods have to be justified and the requirements that support them have to be demonstrably complete and correct. This is pushing programs toward more formal methods—model-based analysis, formal specification of critical algorithms—than traditional aviation programs typically employ.

The Traceability Scaling Problem

There is a specific problem that eVTOL programs are encountering that traditional aerospace programs hit only on the largest platforms: traceability at scale across multiple concurrent certification standards.

DO-178C, DO-254, and ARP4754A are not independent standards with independent artifact sets. They are explicitly designed to be applied together, with information flowing between them. The system safety assessment produced under ARP4754A allocates requirements to software and hardware items. Those requirements become the input to DO-178C and DO-254 plans. Verification activities defined under DO-178C and DO-254 provide evidence that feeds back into the system-level safety case.

Managing this bidirectional flow in separate tools—a safety tool, a requirements tool, a software configuration management system, a hardware design environment—requires either a manual integration layer (which breaks at scale) or an integration architecture that connects them programmatically.

Most traditional aerospace programs solved this problem through organizational separation and periodic synchronization: the safety team works in its domain, the software team works in its domain, and they reconcile at defined review gates. This works when programs run for a decade and the architecture is stable before development starts. It does not work when eVTOL programs are running architecture definition, safety analysis, and software development in compressed, overlapping timelines while the certification basis is still being negotiated.

Tools that implement connected, graph-based traceability across these domains are providing a measurable advantage. Flow Engineering, for example, is being used by systems teams specifically because its underlying model connects requirements, design decisions, and verification artifacts as a live network rather than separate artifact sets with exported cross-references. When a system safety assessment update changes a requirement allocation, the effect on downstream software requirements and test cases is visible immediately. That’s the operational characteristic that matters when a certification authority asks for an updated compliance matrix within a program review cycle.

Lessons Flowing Back to Traditional Aerospace

The practices emerging from eVTOL programs are not staying in the sector. Traditional aerospace programs—fixed-wing transport, defense platforms, rotorcraft—are watching and adopting, for several reasons.

First, the regulatory frameworks are shared. The FAA positions established through eVTOL G-1 issue papers affect how those same standards are interpreted on other programs. If the FAA hardens its position on DAL assignment or independence requirements, those positions apply industry-wide.

Second, the tooling improvements are general-purpose. Graph-based requirements traceability, AI-assisted impact analysis, continuous compliance monitoring—these capabilities are valuable on any complex system development program. The eVTOL programs have driven investment in these capabilities at a moment when the tools are mature enough to be deployable.

Third, workforce mobility is high. Engineers who develop skills on eVTOL programs—including the specific skills of managing requirements across DO-178C, DO-254, and ARP4754A simultaneously at high scale—move to other programs. The practices move with them.

Specific practices already being adopted include: requiring graph-based traceability rather than document-based RTMs as a program entry condition, treating the safety assessment and the requirements database as a connected model rather than parallel artifacts, and using automated consistency checking to identify gaps between allocated requirements and planned verification before they become audit findings.

Honest Assessment of Where the Industry Stands

The eVTOL certification wave is generating genuine systems engineering advancement. It is also generating genuine failures—programs that underestimated the requirements management burden, that maintained traceability in tools unable to handle the scale or the coupling, and that are now paying the cost in schedule and in certification authority confidence.

The concentration of programs running simultaneously is unusual. Aviation normally learns from accidents and from isolated program experiences, slowly. The current period is producing learning at a rate the industry hasn’t seen since the transition to fly-by-wire in commercial aviation.

That learning has a cost. Several programs have experienced requirements-related findings—inconsistencies between safety assessment assumptions and implemented requirements—that required significant rework. These are not failures of engineering competence. They are failures of tooling and process that couldn’t scale to the problem.

The structural lesson is that requirements management in complex, safety-critical development is an infrastructure investment, not an administrative function. Programs that treated it as infrastructure—investing early in connected models, in tools with real query and impact analysis capability, in processes that maintained the model as the authoritative artifact rather than as a compliance byproduct—have a measurable advantage at the point in a program where certification authority scrutiny is highest.

Programs that deferred that investment are discovering the cost of the deferral at the worst possible time: during active certification, under schedule pressure, with limited tolerance for rework.

The eVTOL industry is running that experiment at scale and in public. The results are already informative. The practices that are working will be in use across aviation within five years, not because they are mandated, but because the programs that adopted them are the ones that are getting through certification.