The Quiet Professionalization of UAM Infrastructure Engineering

For most of its short public life, urban air mobility was a marketing category. The renderings were good. The physics were real enough. The regulatory pathway was plausible. But the infrastructure — the vertiports, the airspace management systems, the ground power and charging equipment, the passenger processing flows — was consistently underspecified in public discourse, described in adjectives rather than requirements.

That is changing. Not loudly, but systematically. In 2025 and into 2026, the engineering teams actually building UAM ground infrastructure began producing documents that look less like concept whitepapers and more like systems specifications. Standards bodies convened working groups with engineers who had learned, from bitter experience in adjacent domains, what happens when you defer infrastructure requirements until the vehicle is certified.

What they are discovering is that vertiport integration is among the more complex multi-stakeholder systems engineering problems the aviation industry has attempted. It combines the certification rigor of commercial aviation with the real-estate complexity of urban construction, the operational tempo of transit systems, and the interoperability demands of shared telecommunications infrastructure — all without the decades of accumulated standards that make, say, airport terminal design tractable.

What “Infrastructure” Actually Means in UAM

The word gets used loosely. In UAM, infrastructure spans at least four distinct engineering domains that must integrate cleanly:

Physical vertiport structures. The landing pad itself, the structural loads it must sustain across the vehicle types it will serve, fire suppression systems, passenger pathways, ground crew workspaces, obstacle clearance geometry, and approach/departure surfaces. This is closest to traditional civil engineering, but with requirements that change as vehicle designs evolve.

Energy systems. High-power DC charging infrastructure, battery thermal management, grid interconnects, backup power, and in some designs hydrogen fueling. The load profiles of eVTOL charging — large power draw, fast turnaround, concentrated at peak hours — are a genuine challenge for utility planning.

Ground support equipment (GSE). Vehicle handling equipment, towing, pre-flight service connections, sensors for vehicle health monitoring on the ground. Much of this is bespoke today because no standard vehicle interface exists.

Airspace interface systems. The digital infrastructure that connects vertiport operations to UTM (unmanned traffic management) or ATM systems — scheduling, slot management, conflict detection, meteorological data feeds, and communications with vehicle automation systems.

Each of these domains has its own engineering culture, its own standards heritage, and its own regulatory home. The integration work sits in the white space between them.

The Vehicle-to-Infrastructure Interface Problem

The hardest systems boundary in UAM is not the one between the vehicle and the sky. It is the one between the vehicle and the ground.

Aircraft certification, under both FAA and EASA frameworks, belongs to the vehicle. The vertiport is ground infrastructure, typically subject to local building codes, aviation authority operational approval, and in many jurisdictions a patchwork of both. The result is a classic system-of-systems problem: the safety case for the overall operation requires confident assertions about both the vehicle and the ground systems, but no single regulatory framework currently owns that joint safety case.

This creates specific requirements management pathology. Vehicle OEMs make assumptions about ground systems in their certification basis — approach slope protection, surface load-bearing capacity, wind sensor placement, charging connector specifications — that ground infrastructure operators may or may not be able to honor. Infrastructure operators make assumptions about vehicle behavior — parking precision, power demand profiles, maintenance access needs — that vary across vehicle types and evolve across vehicle generations.

Without a stable, formally documented interface specification, both sides are building to assumptions that will collide in operation. Several early vertiport pilot programs have already encountered this in concrete terms: charging interfaces designed for one vehicle that don’t physically fit another, structural load ratings that became inadequate when a vehicle’s MTOW changed late in certification, approach surface geometries that conflict with obstacle clearance requirements for adjacent vehicle types.

The vehicle-to-infrastructure interface needs to be treated as a formal system interface, with allocated requirements on both sides, managed change control, and verification responsibility explicitly assigned. This is not a novel idea in systems engineering. It is standard practice in defense and space systems integration. It has simply not been applied consistently in the nascent UAM infrastructure domain.

The Standards Landscape: Overlapping, Maturing, Incomplete

Three organizations are doing the most substantive work on UAM infrastructure standards, and their efforts are complementary rather than coordinated.

SAE International has been the most prolific. The AS6969 series addresses vertiport design, covering approach and departure surfaces, obstacle limitation surfaces, and physical dimensions. SAE’s AS-4 committee (Aerospace Actuation, Control and Fluid Power) is developing standards for GSE interfaces. The AIR6914 informational report on eVTOL operations provides a useful requirements taxonomy even where it stops short of mandating specifications.

EUROCAE has been working through its WG-112 committee on UAM, developing material that feeds into EASA’s regulatory framework. The European approach tends toward operational requirements first — what the system must do — before specifying how, which is methodologically sound but requires that operational requirements be precise enough to drive design.

ASTM International published F3411 on remote identification and F3523 on vertiport design elements, with ongoing work in the F38 committee on unmanned aircraft systems that increasingly intersects with UAM.

ICAO is moving more slowly, as it must given its global consensus process, but its work on advanced air mobility will eventually set the framework within which national standards bodies operate.

The practical implication for engineering teams: you are currently operating in a multi-standards environment where the applicable standards depend on vehicle type, operational geography, and the specific infrastructure element being designed. A vertiport serving U.S. operations under FAA jurisdiction will reference different standards than one in EASA Member States, even if they serve the same vehicle type. A vertiport designed to serve multiple vehicle types from multiple operators may need to satisfy requirements that have not yet been harmonized across those standards.

This is not a reason to wait. It is a reason to build requirements structures that can accommodate multiple standards simultaneously and track which requirements flow from which standard — so that when standards harmonize (and they will), the traceability work is manageable.

The Multi-Operator Interoperability Problem

Every serious infrastructure investor in UAM eventually arrives at the same uncomfortable realization: a vertiport that can only serve one vehicle type from one operator is an asset with catastrophically concentrated risk. The operator might not achieve commercial scale. The vehicle might not achieve certification. The route economics might not work.

A commercially viable vertiport needs to serve multiple operators and multiple vehicle types. This is not just a business model consideration. It is a requirements driver that fundamentally changes the complexity of the engineering problem.

Multi-operator interoperability requires:

• Physical interface standards that allow different vehicles to use the same pads, charging connections, and GSE without vehicle-specific tooling for each
• Data interface standards that allow scheduling and operational systems to communicate with multiple operator systems without bespoke integration for each
• Safety case structures that remain valid across vehicle types with different performance envelopes, failure modes, and emergency procedures
• Operational procedures that ground crews can execute consistently regardless of which vehicle is being serviced

None of these exist in complete, ratified form today. What does exist is a set of industry working groups, draft specifications, and parallel pilot programs generating empirical data. The teams doing the best work are treating the interoperability specifications as requirements engineering problems: what exactly must be true at each interface for the overall system to function safely and economically?

No single OEM has a strong commercial incentive to fund this work because the beneficiary of interoperability standards is the infrastructure operator and the industry as a whole. This is a classic public goods problem, and its resolution — as in most infrastructure domains — will require either regulatory mandate or consortium-based pre-competitive standards development.

How Requirements Management Is Evolving

The early phase of UAM infrastructure requirements looked like this: a Word document describing a vertiport concept, reviewed in meetings, revised between meetings, with no systematic traceability to regulations, no linkage between high-level operational requirements and detailed design specifications, and no mechanism to propagate a regulatory change through to all dependent design elements.

This approach is now understood to be inadequate. The certification pressure alone — demonstrating to regulators that your vertiport design satisfies applicable requirements with appropriate evidence — demands more rigorous requirements structures. Multi-stakeholder programs, where a vertiport operator, a vehicle OEM, an infrastructure investor, and a local authority all have requirements that must be reconciled, demand tools that make conflicts visible rather than burying them in email threads.

The migration toward model-based and graph-structured requirements management is visible in the more sophisticated UAM infrastructure programs. Rather than maintaining requirements as flat lists in documents, teams are building requirement networks where relationships between requirements are explicit and queryable — where you can ask “which design elements are affected if this EUROCAE standard changes?” and get a useful answer rather than beginning a manual review.

Tools like Flow Engineering are appearing in these programs precisely because UAM infrastructure’s requirement network structure — regulatory requirements flowing down to operational requirements, operational requirements allocating to subsystem specifications, subsystem specifications tracing to verification activities — is exactly the graph-structured problem that document-based tools handle poorly. When a vertiport must demonstrate compliance with six different standards across four regulatory jurisdictions, the ability to model the requirement relationships and automatically identify impact when something changes is not a luxury.

The alternative — and it is still common — is manual traceability matrices maintained in spreadsheets, where a regulatory change generates weeks of manual impact analysis, where errors in the matrix are invisible until an audit, and where the effort of maintaining the traceability is so high that teams let it drift from reality. That approach does not scale to the complexity of multi-operator, multi-standard vertiport certification.

What Serious Engineering Teams Are Actually Doing

Across the programs doing this work competently, some consistent practices are visible:

Explicit interface definition first. Before detailed design of any subsystem, the external interfaces are formally specified: what comes in, what goes out, in what format, with what timing, with what error conditions handled how. This sounds obvious and is routinely skipped.

Regulatory mapping as a live artifact. Rather than checking regulatory compliance at the end of a design phase, teams are maintaining live mappings between design requirements and the specific regulations, standards, and guidance material they satisfy. When regulations update, the impact is immediately visible.

Operational scenario-driven requirements. Starting from concrete operational scenarios — peak morning departure push with three vehicles on pads, one charging fault, ATC holding instruction received — and deriving requirements from what must be true for those scenarios to execute safely. This produces requirements that are testable rather than aspirational.

Change management as a first-class activity. In a standards environment that is still evolving, the ability to manage change without losing traceability is a core competency, not a process afterthought.

Honest Assessment

UAM infrastructure engineering is genuine. The physics work, the regulatory path exists, and the engineering problems are solvable with discipline. But the sector is still in the phase where it is building the engineering infrastructure — the standards, the interface specifications, the requirements frameworks — that makes serious systems integration possible.

The risk is not that vertiports can’t be built. Several will be built in the next 24 months. The risk is that they get built to incompatible, implicit standards, serving one operator’s vehicles, with requirements documentation that cannot support multi-operator expansion or certification in a second jurisdiction.

The teams that will own the infrastructure in a mature UAM market are the ones that treat this phase — messy, under-standardized, evolving — as an opportunity to build requirements rigor into their programs while the programs are still small enough to be restructured. Retrofitting traceability into a vertiport design that is already in permitting is expensive. Retrofitting it after a certification finding is worse.

The professionalization is happening. It is happening in working groups that don’t generate press releases, in interface control documents that don’t get shared publicly, in requirements reviews that are genuinely hard because the problems are genuinely complex. That is what mature engineering looks like.