By Bjorn Fehrm and Henry Tam
October 17, 2025, ©. Leeham News: We do a series about ideas on how the long development times for large airliners can be shortened. New projects talk about cutting development time and reaching certification and production faster than previous projects.
The series will discuss the typical development cycles for an FAA Part 25 aircraft, called a transport category aircraft, and what different ideas there are to reduce the development times.
We will use the Gantt plan in Figure 1 as a base for our discussions. We added two milestones to our Program Plan, which we will refer to in the articles: Preliminary Design Review and Critical Design Review. Here is their definition according to NASA:
The Preliminary Design Review (PDR) demonstrates that the preliminary design meets all system requirements with acceptable risk and within the cost and schedule constraints, and establishes the basis for proceeding with detailed design. It shows that the correct design options have been selected, interfaces have been identified, and verification methods have been described. The PDR should address and resolve critical, system-wide issues and show that work can begin on detailed design.
The Critical Design Review (CDR) demonstrates that the maturity of the design is appropriate to support proceeding with full-scale fabrication, assembly, integration, and test. CDR determines if the technical effort is on track to complete the system development, meeting mission performance requirements within the identified cost and schedule constraints.
Figure 1. A generic new Part 25 airliner development plan. Source: Leeham Co. Click to see better.
*** Special thanks to Andrew Telesca for helping with this article***
Preliminary Design; Requirements Definition
As we progress through the preliminary design phase, the most critical aspect of certification is finalizing the requirements definition, especially for the technology risks identified in the conceptual design phase. The aim is to translate technology choices into certifiable design requirements and ensure the foundations are solid in areas that can quietly undermine programs, such as software and hardware development assurance and the integration of third-party systems.
In this article, we’ll look at:
- How certification requirements are established for new technologies
- Integrating supplied equipment, including “commercial off the shelf” (COTS) items, into our design
- Building the requirements foundation through development assurance
- Critical influences on execution (resolution) speed
How Certification Requirements are Established for New Technologies
In order to move forward with our carefully accepted list of technology innovation areas, we now need to build new requirements under which they can be certified. On the plus side, there are many regulatory tools that support this process. However, none of them are fast. Active engagement with the regulator’s project team is needed to craft a strategy tailoring the following key tools based on our specific needs:
- Special Conditions (SCs) – Used when existing regulations are not considered adequate to cover the potential hazards of novel technologies, so new regulations must be written.
- Equivalent Level of Safety (ELOS) Findings – Used when direct compliance with the language of a regulation cannot be met, but the design includes compensating design features that achieve the same safety intent.
- Exemptions – Used in cases where the regulation is impracticable to meet with the new technology, and there is a gap to the original safety intent, but the benefits of the technology allow a case to be made that it’s in the public interest to bypass some portion of the regulation.
- Means of Compliance Issue Papers / Certification Review Items – Used when the regulation is adequate as written, but the accepted methods of verifying that requirement has been met need to be adjusted – for example, because our hybrid-electric powertrain will likely have different stresses than a turbofan engine we will likely need to change how it is endurance tested to ensure we’re exposing it to true “redline” conditions.
- Industry Committees – When a new technology is being used by many applicants often the regulators want a consensus standard for how to ensure safety for that technology. In this case, rather than negotiating with individual applicants, industry standards committees such as ASTM and EUROCAE are used to propose new rules. Such committees move as fast – or as slow – as the industry members driving them.
The final output is an agreed certification requirements set, typically captured in documents including a G-1 Issue Paper (FAA) or A-1 CRI (EASA). These documents become the project’s contract between applicant and regulator—it allows us to go into detailed design with clear requirements that won’t change late in the game.
Integration of Supplied Equipment
No aircraft is built in isolation. Engines, avionics, and many other subsystems come from external suppliers, often already certified for other applications. Integrating them correctly is one of the most underestimated drivers of certification schedule.
Suppliers may provide TSO’d/ETSO’d articles (Technical Standard Order, EU TSO), previously certified systems, or “commercial off the shelf” (COTS) components. Each category requires a different level of oversight. Even previously certified articles must be integrated in a way that preserves their original compliance basis. A TSO-approved air data computer, for instance, may need new safety assessments when paired with a different flight control system, or installed in a different physical environment.
COTS components may not have the quality controls in place necessary for the safety standards of our transport-category product. Overlooking these delta-certification efforts can lead to late discoveries, or even the need to change suppliers after the design is completed. As suppliers are brought on board in this phase, careful attention should be paid to the contractual clauses that govern their roles and responsibilities in the certification process.
Special Note: if our project includes changes to previously certificated products, it’s also important to consider our risks (and opportunities) under the Changed Product Rule (14 CFR 21.101 for the FAA). There are special rules for determining when a changed product can utilize the certification requirements for the original design effort, and when updates are required.
Development Assurance & Our Requirements Foundation
Development assurance (DA) is the glue that holds the certification of complex systems together. It ensures that software, hardware, and systems are developed with processes proportional to their safety impact—DO-178C for software, DO-254 for airborne hardware, and ARP4754A for systems.
Normal design practices are not enough here. DA explicitly addresses safety integration and unintended functions—failure paths that standard design methods might miss, especially for complex systems. In a complex development, the ability of the aircraft systems to perform their intended functions in a safe manner and without adverse or unintended behaviors cannot always be established through testing and analysis of the final design. Therefore, in order to minimize the risk of development errors, rigorous design practices must be implemented and followed.
These practices include the need to independently validate the requirements to ensure they are clear, correct, and complete. Verification methods must be established to ensure evidence is collected to show all requirements are met, including in corner cases and without unintended behaviors. Additionally, a layer of process assurance (also known as design quality assurance) is required – this entails independent auditing of the engineering effort ensuring that the agreed development methodologies have been followed in a consistent and robust manner.
For startups, this is often new territory, requiring investment in requirements management systems, configuration management, tool qualification, and assurance personnel – foundational building blocks that aren’t strictly necessary in early prototyping.
The key to going fast is right-sizing: scaling the rigor of assurance activities to the system’s Development Assurance Levels (DALs) so that rigor is targeted to where it’s critical for safety. Over-applying process burden wastes time; under-applying it risks rejection by the regulator. A balanced DA plan leverages foundations built in the conceptual design phase—requirements traceability, a defined safety process, and a clear design iteration plan.
If you’re coming out of this phase without a clear understanding of the required functions, systems interfaces, performance targets, and redundancy needs, you’re probably going too fast. If you’ve defined all your performance tolerances and monitor thresholds, you’re just setting yourself up for rework.
As we progress the project, integration of requirements into the design reviews is essential. Each review (PDR, CDR, etc.) must show traceability from safety requirements to design artifacts, supported by validation evidence. Without this, the design may progress fast on paper but stall at certification.
Managing Speed of Execution
When it comes to regulatory requirements and the impact on program schedule, success depends primarily on scope control and disciplined data development. Just like the previously shown curve on cost-commitment vs. realization, a fast program is one with a properly tailored set of regulatory requirements and processes.
Some key execution approaches that can also help are:
- Early Data Development – both regulators and industry committees struggle to finalize requirements if there is no data to support them. No one wants to be responsible (or liable) for a bad rule that was based purely on engineering judgment. If you want to get the right requirements in place, build a plan for rigorous testing of early prototypes that can serve as a basis for justifying your proposed rules.
- Make Disciplined Use of Assumptions – Sometimes, to design & build quickly, you need to progress a design without all the information necessary to conclude you’ve defined the requirements correctly. By writing requirements in this phase anyway – with the assumptions clearly documented – you can then collect the validation information needed in prototyping to confirm those assumptions and ensure the final requirements coming out of the detailed design phase will be correct and complete. This puts you on the true path to certification rather than a dead end.
The biggest temptation at this phase will be to proceed with the design “at risk” to go fast – after all, we trust our engineers to have made smart choices, right? However, whether you’re a startup or an incumbent, the reality is that smart risk-taking is managed risk-taking.
Each time you choose to proceed with a known deficiency, ask yourself what you need to know to retire the risk, when you need to know to keep the risk contained, and what control is in place to ensure you don’t forget to close it when a whole new set of fires has taken over your attention. It’s a terrible feeling to look back at a PDR deck from three years earlier and realize that $50m issue you’re facing was recognized back then, but later forgotten.
Related