How the eVTOL Industry Is Inventing New Approaches to Interface Management at Scale

A conventional turbofan regional aircraft has a large number of interfaces. A modern eVTOL has a larger number of interfaces in a fraction of the mass. This is not a marginal difference — it is a structural one that breaks the assumptions baked into every interface management practice the aerospace industry developed over the past forty years.

The reasons are not mysterious. Distributed electric propulsion means six, eight, or twelve motor controllers, each with power, data, and thermal interfaces to manage, rather than one or two engines. Fly-by-wire flight controls on an aircraft with no mechanical fallback mean every actuator path carries safety criticality that previously lived in hydraulics. A battery management system on a 500-kilogram aircraft is interacting with motor controllers, the flight computer, the thermal management system, ground support equipment, and the charging infrastructure — simultaneously, continuously, and at speeds that make human-in-the-loop verification during operation impossible. Autonomous flight capability adds another layer: sensor fusion, redundancy management, and air traffic interface that simply did not exist as aircraft-level engineering problems before.

The result is that eVTOL programs are managing interface complexity that has no historical precedent at this vehicle scale, and they are largely doing it with tools and practices built for a different era.

What Interface Management Actually Means in an eVTOL Program

Interface management is the discipline of defining, controlling, and tracing the boundaries between systems. At its core, it answers three questions: What does this system expect from its neighbors? What does it promise to deliver? And how do we know those commitments are still consistent when something changes?

The primary artifact has historically been the Interface Control Document — the ICD. An ICD for a propulsion system interface might specify voltage tolerances, data bus protocols, connector pinouts, thermal limits, and the timing relationships between control signals. In a conventional program, ICDs are authored, baselined, and change-controlled through a configuration management process. They are referenced by system requirements and traced to subsystem specifications.

This model works when interfaces are few enough to be managed as a document library. It begins to fail when the number of interfaces grows past the point where a human engineer can hold the dependency graph in working memory — which is where virtually every eVTOL program operating today is already living.

The Interface Explosion: By the Numbers

To understand the scale, consider the interface surface of a single subsystem on a representative distributed-propulsion eVTOL. A motor controller unit on an eight-rotor aircraft might have:

• Power bus interfaces to the battery management system (voltage, current, protection coordination)
• High-speed data bus interfaces to the flight computer (command, status, fault reporting)
• Thermal interfaces to the airframe cooling circuit (heat rejection rates, coolant flow, temperature limits)
• Mechanical interfaces to the motor mount and rotor assembly (torque paths, vibration limits, fastener specifications)
• Ground support interfaces to maintenance equipment (diagnostic protocols, configuration access, charge management)
• Electromagnetic compatibility interfaces that affect every neighboring system

Multiply those six categories across eight motor controllers, then add the battery system, the flight control computers, the avionics suite, the passenger safety systems, and the ground infrastructure interfaces. A mid-complexity eVTOL program can realistically have more than two thousand discrete interface requirements before accounting for the redundancy architecture that safety-critical aviation demands.

Two thousand interface requirements, in a document-based ICD system, means two thousand points where a change to one subsystem must be manually propagated to every affected document — and every affected requirement — downstream.

Where Current Practice Is Breaking Down

The most common approach in programs launched between 2019 and 2023 was to stand up IBM DOORS or DOORS Next for requirements management, produce ICDs as controlled Word or PDF documents, and maintain a requirements traceability matrix in a spreadsheet or within DOORS. This is not an unreasonable starting point. DOORS is mature, auditors understand it, and experienced systems engineers know how to work within its constraints.

The problem is that DOORS’s architecture — attribute-based, module-structured, document-oriented — was designed to manage requirements within a system boundary, not the relationships between systems. When interface requirements live in DOORS modules that are maintained separately from the ICDs they reference, traceability becomes a manual synchronization problem. Engineers update the ICD, update the DOORS requirement, and hope that every downstream requirement that cites that interface was also updated. At the scale eVTOL programs are operating, this hope is not being consistently fulfilled.

Jama Connect and Polarion offer somewhat better support for cross-product traceability, and programs that adopted them earlier have generally had better change propagation discipline. But the fundamental model — requirements as structured text, relationships as manually maintained links — still requires a human being to decide that a change to a battery interface voltage tolerance is relevant to a motor controller protection algorithm, and to follow that thread through the requirement hierarchy.

The consequence shows up during integration. Late-stage integration failures in eVTOL programs — and there have been enough of them now that patterns are visible — frequently trace back not to a missing requirement, but to an inconsistent interface: two systems each implementing a requirement correctly, but against interface specifications that diverged somewhere in the revision history without anyone noticing.

The Traceability Gap Between System and Subsystem

The specific failure mode that warrants more attention is the vertical traceability gap — the break in traceable connection between a system-level interface requirement and the subsystem-level ICD that implements it.

A system-level requirement might state that the flight control system shall receive motor speed feedback within a defined latency window under all operating conditions. This requirement needs to flow down into a data bus timing specification in the ICD between the flight computer and each motor controller, and from there into the software timing budgets in the motor controller firmware, and from there into the hardware design constraints on the microcontroller selection.

In current practice, this chain is documented, but it is documented across multiple tools, multiple document formats, and multiple organizational boundaries — often including suppliers who have their own requirements management infrastructure that does not directly connect to the prime’s. The system-level requirement exists in DOORS. The ICD exists as a PDF with a version number. The firmware timing budget exists in a supplier’s internal Polarion instance. The connection between these artifacts is a set of document references that must be manually maintained and manually verified.

This is not a hypothetical risk. It is the documented source of integration problems on multiple programs.

What the Industry Is Actually Trying

The engineering community has not been passive about this. Several approaches are emerging, with varying degrees of traction.

SysML-based interface models. Programs influenced by MBSE methodology are attempting to define interfaces natively in SysML, with ICDs generated from the model rather than authored separately. The theoretical advantage is that a change to an interface in the model propagates automatically to every artifact that references it. The practical limitation is that SysML tool ecosystems — Cameo, Rhapsody — are expensive, require significant modeling expertise, and produce interface models that suppliers frequently cannot consume without their own tooling. The generated documents often look different enough from traditional ICDs that review processes have to be re-established.

Graph-based requirements platforms. A newer category of tooling treats requirements and interfaces as nodes in a connected graph rather than rows in a document. When an interface is defined as a graph node, every requirement that references it is a direct edge — not a text citation that must be searched and interpreted, but a machine-readable link. Change propagation can be automated because the dependency structure is explicit. This approach matches the actual topology of eVTOL interface networks better than any document-based model.

Supplier-facing data packages. Some prime contractors are moving away from distributing ICDs as PDFs and instead providing suppliers with structured data exports — typically JSON or XML representations of interface definitions — that suppliers can import directly into their own requirements tools. This reduces transcription errors at the prime-supplier boundary, though it requires agreement on exchange formats that do not yet exist as standards.

Tools built on graph-based architectures, including Flow Engineering, are seeing adoption in eVTOL programs precisely because the connected-node model is a natural representation of distributed propulsion interface networks. When a motor controller interface node changes, the affected requirements — power, thermal, data, EMC — are visible immediately, and the change can be assessed for downstream impact without manually searching through document libraries. For programs dealing with the interface volumes described above, this is not a marginal efficiency gain; it is the difference between a change control process that is actually executable in the available time and one that is nominally defined but practically impossible to follow completely.

The deliberate focus of tools like Flow Engineering on requirements and interface traceability — rather than full PLM, document management, and supplier contract management — means programs still need adjacent tools for some functions. That is a real consideration when evaluating the integration burden of a new platform.

What Has to Change Before High-Rate Production

The eVTOL industry is still, broadly speaking, in the development-to-certification phase. High-rate production — the phase where interface stability matters most, because changes become exponentially more expensive — is three to five years away for the leading programs, and further for the rest.

That window is the opportunity to establish practices that will scale. Several things need to happen.

Interface versioning has to become machine-readable. An ICD with a version number in a PDF header is not a versioning system — it is a label. Before production, programs need interface definitions with explicit version identifiers, machine-readable change histories, and automated notification when a supplier’s baselined interface version diverges from the current prime-level definition. This requires tooling investment and supplier agreement.

The system-to-subsystem traceability chain has to be continuous. The goal is not to have a system-level requirement and a subsystem ICD that both exist — it is to have a traceable, auditable connection between them that survives through the certification basis and into the production configuration. Achieving this requires choosing a requirements architecture that makes cross-document, cross-boundary traceability a first-class capability, not an afterthought.

Supplier interface management has to be part of the procurement conversation. Currently, interface management capability is rarely evaluated as a supplier selection criterion. Before high-rate production begins, primes will need to specify minimum interface data exchange standards as contractual requirements, the same way they specify quality management system certifications today.

Honest Assessment

The eVTOL industry is solving a real and novel engineering problem with a mixture of adapted legacy practice and emerging tooling that is not yet fully proven at production scale. The programs that are farthest along in certification are the ones that invested early in connected, model-based interface management — not because any single tool is perfect, but because the document-based alternative cannot support the change velocity and interface volume these vehicles demand.

The risk is not that the industry lacks capable engineers. It is that capable engineers working in disconnected tools, across organizational boundaries, on interface networks of unprecedented density, will accumulate integration debt that becomes visible at exactly the wrong moment: during type certification testing, or in the first year of commercial operations.

The practices and tools that address this are available now. Adopting them requires treating interface management as a first-order systems engineering discipline — not a documentation overhead, but the connective tissue that holds a distributed electric aircraft together.