Volocopter: Navigating Dual-Jurisdiction Certification for Urban Air Mobility

Volocopter has been flying crewed electric vertical takeoff and landing aircraft since 2016. That’s a decade of flight test data, which is more than most of its eVTOL competitors can claim. The Karlsruhe-based company’s VoloCity air taxi has logged public demonstration flights in Helsinki, Dubai, and Singapore, and the company has secured urban air mobility operating agreements in multiple cities. None of that changes what is in front of the engineering team right now: achieving type certification under two of the world’s most demanding regulatory frameworks at the same time, for an aircraft category that neither framework was originally written to address.

That problem — simultaneous EASA and FAA certification for a novel crewed eVTOL — is one of the hardest systems engineering challenges in aerospace today. Not because either regulator is unreasonable, but because the specific means of compliance, the interpretation of safety objectives, and the certification project management expectations differ in ways that compound across a complex distributed propulsion system.

What Volocopter Is Actually Building

VoloCity is a two-seat passenger air taxi powered by eighteen rotors arranged in a single coaxial-style ring above the cabin. It has no conventional tail rotor, no collective pitch control, and no mechanical backup for flight control — all rotor speed modulation is managed through software. The aircraft is designed for short urban hops, targeting routes of five to fifteen kilometers, with a service ceiling that keeps it well below commercial airspace.

The architecture is intentionally simple from a mechanical standpoint. Volocopter trades mechanical complexity for electrical and software complexity. Eighteen independent electric motors, multiple battery strings, and a fly-by-wire flight control system create a system where redundancy is achieved through replication rather than dissimilar backup mechanisms. From a passenger safety perspective, the argument is that losing one, two, or even several rotors does not compromise controlled flight. From a certification perspective, that argument must be made quantitatively, with verified software, to two regulators who have different expectations for how the argument is structured.

The Regulatory Landscape: Where EASA and FAA Agree — and Where They Don’t

Both EASA and the FAA have acknowledged that their existing frameworks — CS-23 and FAR Part 23 respectively — were written for conventional fixed-wing aircraft and are not straightforwardly applicable to a distributed-electric-propulsion VTOL with no certified precedent. Both regulators responded by developing special conditions.

EASA issued its Special Condition for VTOL aircraft (SC-VTOL) in 2019, establishing airworthiness requirements covering lift and propulsion, flight envelope, handling qualities, and emergency landing. The FAA has used AC 21.17-4 and issue papers to establish certification basis on a project-specific basis. Both point to ARP4754A as the acceptable means of compliance for systems and equipment development assurance — that’s the point of genuine alignment between the two regulators.

The divergence surfaces in the details. EASA and FAA do not always agree on the acceptable probability thresholds for catastrophic failure conditions. They differ on the specific means of compliance for novel propulsion architectures. EASA’s approach to safety assessment tends toward more prescriptive functional hazard analysis documentation; the FAA has historically allowed more flexibility in structuring the safety argument provided the quantitative case is made. The gap between “acceptable to EASA” and “acceptable to FAA” for any given design decision is not always large, but in a certification program with thousands of requirements, small gaps aggregate into significant engineering work.

Volocopter must not only satisfy both sets of requirements — it must produce certification documentation that each regulator’s Certification Office can review independently, in the order and format each office expects, without the documentation of one confusing the review of the other. Managing that dual-track program, for a novel aircraft, is a project management and systems engineering problem as much as it is an engineering problem.

ARP4754A in a No-Precedent Context

ARP4754A is the SAE standard that defines development assurance processes for civil aircraft systems and equipment. Both EASA and the FAA reference it as an acceptable means of compliance for demonstrating that complex systems have been developed with appropriate rigor. For Volocopter, applying ARP4754A to VoloCity means working through functional hazard assessment, preliminary system safety assessment, system safety assessment, and common cause analysis — the standard safety assessment sequence — for a distributed-propulsion architecture that has no certified analog.

The absence of precedent cuts both ways. There are no legacy design decisions that constrain the architecture, which gave Volocopter freedom early in the program. There is also no body of accepted certification data to reference, which means every safety claim must be built from scratch and every argument must be made to a regulator who is simultaneously learning how to evaluate it.

The critical tension is at the top of the development assurance hierarchy. ARP4754A assigns Development Assurance Levels to functions based on the severity of failure conditions identified in the functional hazard assessment. For VoloCity, loss of controlled flight is catastrophic — that’s unambiguous. The functions that prevent loss of controlled flight are therefore DAL A. DAL A means the most rigorous development process: independence between development and verification, complete traceability from requirements through design through code through test, and tool qualification for any automated tool that produces DAL A outputs.

Applying DAL A rigor to a flight control system built around eighteen novel motor controllers, custom battery management software, and a flight management computer with no certified heritage is an enormous undertaking. Volocopter cannot reach back to a legacy certified component and rely on prior approval. Every artifact — every requirement, every design description, every test case, every verification result — must be produced and reviewed under DAL A discipline. That is what the VoloCity certification program actually requires, stripped of marketing language.

DO-178C and DO-254: The Software and Hardware Assurance Layer

Below ARP4754A in the compliance hierarchy, DO-178C governs software development and DO-254 governs complex electronic hardware development. Both standards are explicitly invoked for DAL A through DAL C software and hardware in the VoloCity certification basis.

DO-178C at DAL A requires 100% modified condition/decision coverage — MC/DC — for structural coverage of flight-critical software. It requires independence in software verification: the person or team reviewing the code and tests cannot be the same as the person or team who wrote them. It requires qualification of any software tool that automates a DO-178C activity and whose output is not subsequently verified by hand. For a modern embedded software development environment — compilers, model-based design tools, code generators, static analysis tools — tool qualification is itself a substantial program.

The intersection with dual-jurisdiction certification is worth stating explicitly. DO-178C is the same standard whether EASA or FAA is the certifying authority. The process requirements are the same. But the regulatory review process is not identical. EASA’s Certification Directorates and the FAA’s Aircraft Certification Offices have different review traditions, different delegation arrangements with their authorized representatives, and different internal processes for evaluating software review findings. Volocopter must produce a single body of DO-178C evidence that can survive parallel scrutiny from both offices without internal contradiction.

Organizational Structure and the Engineering Team’s Challenge

Volocopter has structured its engineering organization with dedicated certification engineering functions — teams whose primary responsibility is maintaining the compliance argument as the design evolves, rather than advancing the design itself. This is a deliberate choice, and the correct one for a program of this complexity.

The practical demand on those teams is bidirectional traceability maintained in real time. When a design change modifies a flight control algorithm — and at this stage in a certification program, changes are continuous — the certification team must immediately understand which requirements are affected, which safety assessments reference those requirements, which test cases cover those requirements, and which regulatory commitments reference those test cases. In a dual-jurisdiction program, a design change can create compliance gaps in the EASA argument that do not exist in the FAA argument, or vice versa, because the requirements differ. Detecting that asymmetry requires traceability infrastructure that spans both regulatory frameworks simultaneously.

Organizations that manage this in word processors and spreadsheets discover the problem when a regulator finds it in review. At that point, the cost is not just rework — it is schedule disruption to a certification timeline that is already under investor and market pressure.

What Volocopter’s Certification Program Signals for the Industry

Volocopter is further along in its certification journey than most of its eVTOL competitors. That is not the same as saying certification is close. Both EASA and the FAA have maintained that novel aircraft categories require evidence-based learning as the review progresses, and that timeline estimates from applicants consistently underestimate the time regulators need to develop internal acceptance criteria for genuinely new technology.

The specific challenge of distributed-propulsion fault tolerance is still being worked through at the regulatory level. When the safety argument depends on software-defined response to rotor failure, and when the software itself is under DAL A development assurance, the regulator must be confident both that the software is correct and that the failure modes it responds to have been completely identified. Completeness of failure mode identification for a system with 18 rotors, multiple battery strings, and a fly-by-wire architecture interacting in operational airspace is a non-trivial claim. It requires systematic methods — formal or semi-formal hazard analysis, architectural analysis for common cause failures, verification of fault detection and isolation logic — applied with rigor that scales across the system complexity.

This is the systems engineering challenge that defines Volocopter’s program right now. Not the aerodynamics, which are well understood. Not the battery technology, which is commercially mature. The challenge is building and maintaining a complete, consistent, and auditable engineering argument — from operational concept through certified hardware and software — that two independent regulatory authorities will accept as evidence that the aircraft is safe to carry passengers over cities.

Honest Assessment

Volocopter has genuine advantages over most of its eVTOL competitors: real flight hours, real regulatory engagement history, and an organizational structure that takes certification seriously as an engineering discipline rather than as a documentation exercise performed at the end of development.

The program’s vulnerabilities are the same vulnerabilities that affect every novel aircraft certification: regulatory timeline risk that is outside the applicant’s control, and requirements management complexity that scales faster than headcount. The dual-jurisdiction structure compounds both. A regulator finding in one jurisdiction creates review pressure in the other. A requirements change driven by one regulator’s issue paper may require re-analysis of safety assessments that the other regulator has already reviewed.

Managing that complexity well — maintaining the traceability, catching the asymmetries early, keeping the engineering argument coherent across two regulatory frameworks and thousands of requirements — is as much a systems engineering tooling and process problem as it is a staffing problem. Organizations that have solved this at the infrastructure level spend their engineering talent on the hard technical problems. Organizations that are still solving it at the spreadsheet level spend their engineering talent on document maintenance.

Volocopter’s path to certification runs through both challenges simultaneously. The flight hours are real. Whether the engineering infrastructure matches the ambition of the certification program is the question the industry is watching.