How eVTOL Programs Are Managing the Aerospace-Automotive Supply Chain Collision

The promise of electric vertical takeoff and landing vehicles rests on a manufacturing premise that has never been tested at scale: build aviation-certified hardware using a supply base that looks more like a Tier 1 automotive ecosystem than a legacy aerospace supply chain. Battery cells from consumer electronics suppliers. Motor controllers from EV drivetrain integrators. Structural composites from aerospace primes. Carbon fiber battery enclosures from automotive lightweighting shops. All of it, eventually, on the same vehicle with a single FAA type certificate.

The requirements management implications of this are severe and largely underestimated. This is not a procurement challenge. It is a systems engineering challenge — one that plays out at the intersection of incompatible quality management frameworks, incompatible failure mode languages, and incompatible assumptions about what “traceability” means.

Two Supply Chains, Two Quality Systems, One Certification

Aviation suppliers operate under AS9100. Automotive suppliers operate under IATF 16949. Both are ISO 9001 extensions. Both claim rigorous quality management. In practice, they diverge in ways that matter enormously for an eVTOL program.

Traceability expectations. AS9100 requires traceability to raw material certificates, processing records, and first-article documentation in a form that supports DER-level review. IATF 16949 requires production part approval process (PPAP) documentation — comprehensive, but structured around volume production validation rather than certification evidence packages. An automotive supplier presenting a PPAP package to an FAA DER is presenting the right data organized in a way that answers different questions than the DER is asking.

Audit cadence and corrective action. Aviation suppliers are accustomed to customer source inspection, first article inspection (FAI) per AS9102, and formal corrective action via 8D or equivalent processes with defined closure timelines. Automotive suppliers operate with internal audit cycles tuned to production rate, not certification milestones. A supplier building prototype quantities for an eVTOL program may have no mechanism for the kind of configuration-frozen build documentation an aviation DER expects.

Nonconformance vocabulary. This one causes the most invisible damage. An automotive supplier’s quality system will classify a nonconformance by severity, occurrence likelihood, and detectability — the FMEA triad. An aviation quality system will classify nonconformances against failure condition categories derived from the aircraft’s safety assessment: catastrophic, hazardous, major, minor. These are not the same thing organized differently. They are the outputs of fundamentally different analytical approaches to risk. When an automotive supplier flags a “Severity 8” motor controller anomaly, no one on the aviation side knows whether that means the vehicle falls out of the sky or a status LED is unreliable.

How AC 21.17-2 Shapes Supplier Requirements

FAA Advisory Circular 21.17-2, which governs the use of industry standards in the certification of powered lift aircraft, is where eVTOL programs either gain significant certification leverage or create significant downstream problems.

The AC provides a path for applicants to use existing airworthiness standards — from Part 23, Part 27, Part 33, or combinations thereof — as the basis for showing compliance with the powered lift regulations. The certification basis decision the applicant reaches with their FAA ACO team directly determines which components must demonstrate aviation-qualified performance and which may be accepted under equivalent means.

This is not a theoretical distinction. If your certification basis places a motor controller under Part 33 (aircraft engine) equivalency, that motor controller’s supplier is now in an aviation supply chain with the full traceability and quality system implications that entails. If the same motor controller is accepted under a means of compliance that relies on redundancy architecture and system-level safety analysis rather than component-level qualification, the supplier requirements change substantially.

Programs that have worked through this carefully — Joby, Archer, and Wisk have all published enough about their certification approaches to draw reasonable inferences — appear to be making explicit supplier tier decisions based on failure condition categories from their system safety assessments. Components in the failure path to catastrophic or hazardous conditions get aviation-grade supplier requirements. Components in the failure path to major or minor conditions may be managed under automotive-equivalent regimes with specifically negotiated flow-down requirements.

What makes this complex is that the failure condition categories are outputs of the safety assessment process, which is itself iterative. Supplier qualification decisions made in Phase 1 of a program may be invalidated by safety assessment updates in Phase 2. Programs that haven’t built a live connection between their system safety assessment and their supplier requirements documents are managing this change propagation manually — which means they often aren’t managing it at all.

The Supplier Requirements Translation Problem

The practical failure mode for eVTOL programs is not that they don’t understand what aviation requires of their suppliers. It’s that they hand automotive suppliers aviation requirements documents and expect them to self-identify the gaps.

An automotive motor supplier given an AS9100 gap assessment and a requirements flow-down document that references DO-178C, ARP4754A, and ARP4761 is receiving documents that map to no internal process they have. Their quality team knows DFMEA. Their engineering team knows ASPICE. Their production team knows PPAP. None of these map cleanly to “show me your requirements capture process compliant with ARP4754A Section 5.3.”

Leading programs are building what might be called supplier requirements translation layers — formal program documents that express aviation traceability and quality obligations in terms that automotive suppliers can directly act on. Instead of: “Supplier shall maintain configuration control per AS9100D clause 8.1.3,” the translation layer says: “Supplier shall freeze hardware configuration at PDR equivalent milestone, maintain a change log against that baseline with part number and revision documentation, and submit any post-freeze changes for customer review before implementation. Changes affecting motor output torque, thermal management performance, or fault detection logic require formal DER notification via [process reference].”

This is more work to write. It is vastly less work to manage. The suppliers can actually do it.

Failure Mode Vocabulary: The Bridge That Must Be Built Explicitly

The vocabulary mismatch between aviation safety analysis and automotive FMEA isn’t just a communication problem — it’s a traceability integrity problem.

Aviation certification requires that every requirement allocated to a supplier can be traced back to a system safety assessment, which in turn traces to the aircraft-level failure condition analysis. The connection runs: aircraft-level safety objective → system function requirement → component performance requirement → supplier specification. If any link in that chain uses incompatible terminology or lives in a disconnected document, the traceability doesn’t hold for DER review purposes.

The specific bridge that needs to be built is between FMEA severity scales and aviation failure condition categories. This is not a lookup table. It requires engineering judgment applied at the system boundary: the FMEA is analyzing component-level failure modes; the aviation safety assessment is analyzing aircraft-level failure conditions. A single component FMEA severity rating may map to different aircraft-level failure conditions depending on the operating context, the redundancy architecture, and the specific failure mode.

Programs that are doing this well are building explicit “safety-to-FMEA translation matrices” as controlled program documents, reviewed by both the system safety team and the supplier quality team, and updated every time the safety assessment revision changes a failure condition category assignment. The matrix is not a set-it-and-forget-it document; it’s a live artifact that drives supplier notification decisions.

Building a Requirements Management Process That Works Across Both Domains

The operational challenge for eVTOL program teams is that the requirements management processes needed to handle this are beyond what most legacy tools were designed to support.

IBM DOORS and DOORS Next are entrenched in aviation supply chains. They handle requirements traceability, support AS9100 change management workflows, and are deeply familiar to DERs and certification consultants. They are also document-model tools — they represent requirements as attributes in a database that ultimately produces documents. Managing the live connection between a safety assessment and a supplier requirements document in DOORS is a manual process involving link maintenance across multiple module hierarchies.

Jama Connect handles cross-domain traceability better than DOORS and is used by a number of eVTOL programs for its test management integration. Its supplier portal features are improving, but the tool’s model is still fundamentally document-and-relationship-centric rather than graph-native.

Polarion and Codebeamer both have aviation pedigree and support complex traceability, but their configuration overhead for a startup eVTOL program is substantial, and neither was designed with the automotive-aerospace boundary problem in mind.

Tools like Flow Engineering, which are built natively around graph-based requirements models and designed specifically for hardware and systems programs, offer a different approach to this problem. Instead of maintaining parallel document sets — one for aviation suppliers, one for automotive suppliers — with manual synchronization, a graph-based model lets the program team represent requirements once, at the level of the safety assessment, and derive downstream supplier requirements that are live-linked to their source. When the safety assessment changes a failure condition category, the impact on supplier requirements is immediately visible as a change propagation through the model rather than a search-and-update exercise across Word documents. For programs actively managing the aviation-automotive supplier boundary, the ability to see the full requirements chain from aircraft-level objectives down to supplier line items — and to know automatically which supplier documents need updating when upstream requirements change — is a material operational advantage.

The deliberate focus of tools like Flow Engineering on this kind of connected systems engineering model means they don’t replicate all the document management features of DOORS or all the test management depth of Jama. Programs with extensive legacy DOORS content will need to plan that integration. But for programs building their supplier requirements management process from scratch, the graph-native approach aligns better with the actual problem structure.

What the Leading Programs Are Actually Doing

Across publicly available certification progress reports, conference presentations at AIAA Aviation and AHS Forum, and statements by certification teams, a few consistent patterns appear in the programs making measurable progress:

Explicit supplier tiering based on failure condition analysis. Not a generic “aviation suppliers” and “automotive suppliers” split, but a formal tier assignment that follows directly from the system safety assessment. Tier assignments are controlled documents with change history.

Flow-down requirements written for the supplier’s quality system, not for the OEM’s. The obligation is aviation; the language is automotive. Suppliers are audited against what the translation layer says, not against AS9100 directly.

Joint FMEA-to-safety-assessment review sessions. At major safety assessment revision points, program safety engineers and supplier quality engineers review the translation matrix together. This is a calendar event, not an ad hoc process.

Configuration control gates tied to certification milestones. Hardware configuration freeze dates for automotive suppliers are aligned to aviation program milestones (PDR, CDR, TIA application), not to the automotive development calendar.

Single requirements model spanning both supply chain domains. The programs further along in certification are moving away from parallel document sets and toward unified requirements models where the source-of-truth for supplier requirements is the same artifact that feeds DER evidence packages.

Honest Assessment

The eVTOL supply chain problem does not have a fully solved state yet. Every program currently in the FAA certification process is, to some degree, inventing the process as it goes. The AC 21.17-2 flexibility that makes eVTOL certification tractable also means there is no single established playbook for what automotive supplier requirements must look like.

What is clear is that programs treating this as a procurement or supplier development problem — rather than a systems engineering and requirements management problem — are accumulating certification risk that will be expensive to resolve. The conflict between aviation and automotive quality systems is not resolved by auditing automotive suppliers against aviation standards. It is resolved by building a requirements management architecture that can represent both domains coherently, trace between them, and propagate changes without manual intervention.

The programs building that architecture now, in early phases, will be materially faster through DER review than programs still maintaining parallel Word documents when they reach their type inspection authorization applications.