Requirements Management Across the Full eVTOL System-of-Systems

Most eVTOL programs treat the aircraft as the system. It is not. The aircraft is one node in a system-of-systems that also includes vertiports, ground power and charging infrastructure, air traffic management (ATM) integration, dispatch and fleet management software, and the human operators who bridge all of them. A passenger boards at a vertiport, the aircraft talks to an Advanced Air Mobility (AAM) service provider for corridor authorization, a charger must hit a specific state-of-charge window before the next departure, and the dispatch system must know when that window is met.

Every one of those interactions is governed by a requirement. Most eVTOL programs cannot tell you who owns it, which document it lives in, or whether it has ever been verified.

That is the real requirements management problem in AAM — not whether the aircraft’s DAL assignments are correct (though they matter), but whether the full system-of-systems has a coherent, traceable requirements architecture at all.

What “System-of-Systems” Actually Means for eVTOL

The term is overused. For practical purposes, a system-of-systems has two defining properties: (1) each constituent system has independent operational utility, and (2) the emergent behaviors that matter for the mission arise from the interactions between systems, not from any single system alone.

An eVTOL operation fits this definition precisely. The aircraft can fly without the vertiport software talking to it — for a while. The vertiport can operate without the ATM service provider’s corridor data — until airspace gets busy. The charging system can charge without the dispatch algorithm knowing about it — until the airline misses a turn cycle. The emergent failure modes are operational, commercial, and eventually safety-critical. They live in the interfaces.

For a requirements program, this means the requirements architecture must explicitly model:

  • System boundaries: What is inside the FAA-certificated aircraft product? What is outside it?
  • Interface control: Who owns the specification of each interface? How are changes to that specification managed?
  • Derived requirements: What does the aircraft need the ground infrastructure to do, and vice versa? Are those needs written down and agreed to?
  • Verification ownership: Which organization is responsible for verifying system-level behaviors that span a boundary?

None of these questions have automatic answers. You have to build the answers into your requirements architecture intentionally.

How ARP4754A Handles — and Doesn’t Handle — System-of-Systems Boundaries

ARP4754A (Guidelines for Development of Civil Aircraft and Systems) is the primary guidance document for civil aircraft system development assurance. It defines a development process from aircraft-level functions down through system and item levels, with rigor proportional to the failure condition severity determined during Functional Hazard Assessment.

ARP4754A is rigorous within the aircraft boundary. It handles multi-system interactions well when all systems are part of the certificated aircraft product. What it does not handle well — because it was not written to — is the boundary between the certificated aircraft and external systems that are not part of the type certificate.

The document uses the concept of assumed conditions: when a system depends on an external input, that dependency can be documented as an assumed condition on the external system. This is the formal mechanism for handling the aircraft-to-ground interface. But assumed conditions are only as good as the rigor applied to them, and ARP4754A does not prescribe how to verify that external systems actually meet the assumptions.

For eVTOL programs, this creates three specific risks:

1. The assumption is never written down. The aircraft team assumes the vertiport can deliver 400kW of charging within a 3-minute connect window. The vertiport team does not know that assumption exists. Nobody wrote an interface requirement. The two teams are building to different mental models.

2. The assumption is written down but never agreed to. The aircraft team documents the assumed condition in their ICD. The vertiport team never signs it. When the vertiport delivers 320kW because that is what their supplier’s hardware supports, neither team has a contractual or technical mechanism to resolve the gap quickly.

3. The assumption is agreed to but the verification is not planned. Both teams agree on the interface requirement. Neither team’s V&V plan covers the system-level behavior that depends on the interaction. It emerges as a gap during integrated testing, late and expensive.

ARP4754A provides the framework for making assumptions explicit at the aircraft level. Extending that framework to cover the full system-of-systems requires deliberate program-level architecture work that the guidance document does not prescribe.

Allocating and Owning Interface Requirements

The practical question is: who owns the requirement that the vertiport charging system shall deliver power within X seconds of aircraft-reported readiness?

There is no universal answer, but there is a principled one. Interface requirements should be owned at the level of the interface, not at the level of either constituent system. This means:

  • Interface Control Documents (ICDs) should be first-class program artifacts, not outputs of either subsystem team. They should have their own change control, their own approval process, and their own traceability into both subsystem requirements sets.
  • Each interface requirement should have a verification owner: the organization or team responsible for demonstrating, by test or analysis, that the interface behavior meets the requirement in the operational environment.
  • Bidirectional traceability must exist: from the interface requirement up to the system-level need it supports, and down to the implementation-level specifications in each subsystem.

In practice, most eVTOL programs assign ICDs to whoever writes them first — usually the aircraft team, because aircraft teams have the most experience with formal documentation. This creates a structural imbalance. The aircraft team’s assumptions become the interface requirements, and the vertiport or ATM integration team inherits constraints they had no input to.

A better approach: treat each interface as a negotiation between two owning teams, mediated by a systems engineering function that holds the program-level requirement context. The interface requirement is not finalized until both sides agree it is achievable and testable.

The Certification Challenge at the FAA/Non-FAA Boundary

FAA oversight of AAM operations is evolving. Under current frameworks, the type-certificated aircraft product must meet Part 23, Part 25, or the applicable special conditions for novel configurations. The vertiport is being addressed under advisory circulars for heliport design, with AAM-specific guidance in development. The ATM integration for AAM corridors is being developed under the AAM National Campaign and the UTM ecosystem. Charging infrastructure has no dedicated FAA regulatory framework.

This creates a certification map with a hard boundary: inside the type certificate, rigorous assurance requirements apply. Outside the type certificate, the program is largely on its own.

The risk is not that non-regulated systems are unsafe — it is that the safety argument for the regulated system may silently depend on behaviors of non-regulated systems. If the aircraft’s battery management system assumes a specific charging protocol that the ground charger can violate, and there is no contractual or operational mechanism to prevent that violation, then the aircraft’s safety case has an undocumented external dependency.

The FAA’s current guidance for novel aircraft configurations (through the Aircraft Certification Service Issue Papers and Special Conditions) increasingly asks applicants to identify and document these external dependencies explicitly. That is the right direction, but it places the burden on the applicant to have a requirements architecture that makes the dependencies visible.

The practical implication: every requirement in the aircraft requirements set that is satisfied by or depends on the behavior of a non-certificated external system must be flagged, and the assumed behavior of that external system must be documented and justified. This is not optional from a certification standpoint — it is the mechanism by which the safety argument remains coherent.

Why Siloed Documents Fail This Problem

The standard industry response to the eVTOL system-of-systems problem is a collection of documents: an aircraft System Requirements Document, a Vertiport Interface Control Document, an ATM Integration Specification, a Charging System Protocol document. Each lives in a different folder, owned by a different team, on a different release cadence.

The failure mode of this approach is not that any single document is wrong. It is that the connections between documents are informal. When the ATM integration team updates their corridor authorization protocol, nobody automatically checks whether the aircraft’s mission computer timing requirements are still satisfied. When the vertiport team changes their charging connector specification, nobody automatically checks whether the aircraft’s ground power assumed conditions are still valid.

In document-based systems, change propagation is manual. Someone has to know to check. In practice, someone does not know, or does not have time, and the gap persists until integration or, worse, until operational testing.

How a Graph-Based Requirements Platform Changes the Architecture

Flow Engineering is built around a graph model of requirements: every requirement is a node, every relationship — derives-from, satisfies, allocated-to, verified-by, interfaces-with — is a typed edge. The full system-of-systems requirements architecture lives in one model, not in a collection of linked documents.

In this model, the eVTOL program’s aircraft requirements, vertiport interface requirements, ATM integration requirements, and charging protocol requirements are all nodes in the same graph. When a requirement changes, the graph model makes the affected edges immediately visible. A change to the vertiport charging power specification propagates through the graph to surface every aircraft requirement and assumed condition that depends on it.

This is not a document management feature. It is an architectural property of how requirements are stored and related. The difference matters operationally: instead of asking “did anyone remember to check all the downstream impacts?”, you ask the model to show you the impact graph for the change. The model answers.

Flow Engineering also supports multi-team requirements ownership within a single model. The aircraft team owns their nodes; the vertiport integration team owns theirs; the interface requirements are co-owned with explicit approval workflows. Change control operates at the requirement level, not the document level, which means a vertiport team update to a connector specification triggers the right aircraft team review without requiring manual coordination.

For certification, this architecture provides something document-based systems cannot: a traceable record showing, for every aircraft-level assumed condition, the chain of requirements in external systems that justify the assumption. The FAA reviewer can see not just that the assumption exists, but that it is governed, tracked, and has a verification plan.

Flow Engineering’s current focus is on early-stage and growth-stage engineering programs — it is not a legacy document migration tool, and it is not designed to serve programs whose primary workflow is already locked into DOORS or Jama. That is a deliberate scope choice. For an eVTOL company building its requirements architecture from the ground up, that focus is an advantage: the platform is built for the architecture you need to create, not the architecture that existed before AAM existed.

A Practical Starting Framework

If you are an eVTOL systems engineering lead trying to apply this today, here is a concrete starting sequence:

Step 1: Map the system boundary explicitly. Draw the line around the certificated aircraft product. Document every external system that the aircraft interacts with operationally. This is your system-of-systems map. If it does not exist as a formal artifact, create it before doing anything else.

Step 2: Enumerate the interfaces. For each external system, list every interaction: data exchanged, physical connections, timing dependencies, operational protocols. Each interaction is a candidate interface requirement.

Step 3: Assign ownership to every interface requirement. Not “the aircraft team” or “the vertiport team” — a named individual or named function with explicit approval authority. Without ownership, requirements drift.

Step 4: Flag every aircraft requirement that depends on external behavior. These are your assumed conditions in ARP4754A terms. Document the assumption explicitly. Create a corresponding requirement (or assumption record) in the external system’s requirements set. Establish traceability between them.

Step 5: Build the verification plan across the boundary. For every interface requirement, identify who will verify it, in what environment, and at what program phase. Do not leave system-level interface behaviors to emerge during integrated test.

Step 6: Choose a requirements platform that can hold the full graph. If your requirements for aircraft, vertiports, ATM, and charging live in separate tools with no formal traceability between them, you cannot execute steps 1 through 5 effectively at scale. The platform choice is an architectural decision, not a tooling preference.

Honest Assessment

The eVTOL industry has excellent aircraft requirements engineering talent, imported largely from aerospace primes. It has much thinner capability in system-of-systems requirements architecture, because that discipline has historically lived at the program level of very large defense and space programs — not at early-stage startups flying small aircraft.

The gap will be closed by programs that treat the aircraft as one node in a system-of-systems from day one, build their requirements architecture to reflect that reality, and choose tooling that can hold the full model without forcing it into document-shaped containers.

Programs that defer this work will close the gap later, in certification, at higher cost, under schedule pressure. The technical problems are solvable. The question is when you solve them.