TSO authorization
Certification plan support for TSO authorization
A TSO certification plan review checks that the plan an applicant submits to open a program describes a basis, a set of affected areas, and compliance commitments the data package can actually deliver. Equipment suppliers use it before the plan goes to the FAA, so the commitments made up front do not outrun what engineering will produce. It reads the stated basis against the article's standard, checks that every promised method has a home in the work ahead, and finds places where the plan commits to coverage the program has no path to. You get a gap assessment against the plan, a map from each commitment to the evidence that will satisfy it, and a closure plan for the commitments that lack one.
When this review is needed
- A TSO program is about to open and the plan is the first document the FAA will read and hold the applicant to.
- An earlier plan promised methods the program later could not deliver, and a revision is being written.
- The article's software or hardware assurance level is being set and the plan has to commit to the right lifecycle data.
- A team new to TSO work is drafting its first plan and wants the commitments checked against what the data will support.
The problem
The plan is written early, when the design is least settled, yet the FAA holds the applicant to what it says. Commitments get made to a schedule and an optimistic view of the article, and the gap between the plan and the delivered data only shows when reviewers compare them. A plan that over-promises is harder to walk back than one that scoped the work honestly from the start.
What gets reviewed
- The stated certification basis checked against the article's standard and its intended function
- Affected areas and the assurance levels the plan assigns to software and hardware
- Each compliance commitment matched to a method the program can actually run
- Review and coordination milestones the plan promises the FAA
- The lifecycle data the plan commits to for DO-178C and DO-254 at the assigned levels
- Places where the plan asserts coverage the design and schedule cannot support
Scope this review
Tell us the asset, the event, and the evidence in scope, and we will outline a focused first engagement.
Identify what is missing against the means of compliance.
What gets validated
- The certification basis in the plan matches the applicable standard for the article
- Every compliance method the plan names maps to a data item the program will produce
- Assigned software and hardware assurance levels are consistent with the article's function and safety role
- Affected areas in the plan account for the article's real interfaces, not a generic scope
- Milestone commitments to the FAA are achievable against the program's actual sequence
Evidence normally required
- The draft certification plan or its predecessor for the article
- The article's standard, intended function, and preliminary safety role
- The assurance levels proposed for software and hardware
- The program schedule and the methods engineering intends to use
- Any prior plan the FAA has already commented on
Common discrepancies
- A compliance method named in the plan with no corresponding data item in the work ahead
- An assurance level set below what the article's function warrants
- Affected areas described generically rather than for this article's interfaces
- A milestone the plan commits to that the program sequence cannot meet
What is at stake
A plan that commits to methods the program cannot deliver forces a revision cycle with the FAA already engaged, which costs more than getting the scope right before submission. Under-scoping the assurance level or the affected areas means the data package arrives short of what the plan implied, and the applicant answers for the mismatch at the worst moment.
How the work runs
Read the basis
Check the plan's stated certification basis against the standard and the article's function.
Test each commitment
Confirm every promised method has a data item and a place in the work ahead.
Check the assurance levels
Confirm software and hardware levels match the article's function and its safety role.
Close the scope gaps
List commitments with no delivery path and hand off a plan to resolve them before submission.
What the buyer receives
- A gap assessment against the plan's commitments and basis
- A commitment-to-evidence map showing what will satisfy each promise
- A closure plan for the commitments the current program has no path to
Who uses the output
- Certification leads who own the plan the FAA will hold the program to
- Engineering owners aligning the promised methods with the work they will run
- Program managers testing whether the plan's milestones fit the real schedule
How the work fits into the transaction or program
The plan opens the program and sets the frame the compliance matrix and every data report are later measured against. This review runs before submission so the commitments are realistic, then the matrix and the lifecycle data are built to satisfy exactly what the accepted plan promised.
Start with a single asset
Reduce finding cycles by checking the package first.
Jurisdiction-specific considerations
The plan is written to open an FAA TSO program, so its basis, milestones, and coordination points follow FAA process. The assurance-level rationale it sets can inform a later program under another authority, but the plan itself is scoped to FAA acceptance and the review does not treat it as portable.
Regulatory limits
The review checks that the plan is complete, internally consistent, and matched to deliverable data. It does not accept the plan, set the certification basis on the FAA's behalf, or commit the authority to the methods the plan proposes.
What this review does not cover
- Negotiating the plan or its basis with the FAA
- Producing the lifecycle data the plan commits to
- Setting the article's assurance level as a regulatory decision
Specific to this review
- The plan is drafted when the design is least settled but binds the applicant hardest, so honest scoping up front is cheaper than a revision with the FAA already engaged.
- An assurance level set too low in the plan cascades: the lifecycle data is then built to the wrong rigor and has to be redone rather than merely re-documented.
- Affected areas written generically pass an early read but fail later, because the article's real interfaces surface requirements the generic scope never planned for.
Sources
U.S. Government (eCFR). Type certificates, STCs (Subpart E), TSO authorizations (Subpart O), PMA (Subpart K), and export airworthiness approvals (Subpart L).
RTCA. Environmental qualification test categories and procedures referenced by TSO and equipment qualification.
RTCA. Objectives and lifecycle data for airborne software assurance, by design assurance level (DAL A-E).
RTCA. Design assurance objectives and lifecycle data for airborne electronic hardware (FPGA/ASIC/PLD).
Federal Aviation Administration. FAA type certification process, certification basis establishment, and compliance findings.
Frequently asked questions
How does the plan relate to the compliance matrix?
The plan sets the commitments and the matrix later proves each one is met. If the plan commits to methods the program cannot deliver, the matrix inherits the gap, so scoping the plan realistically is what keeps the matrix honest later.
Relevant glossary terms
Related pages
Where this fits
Talk to an engineer who has done this work
We will walk through your current state, the records or evidence involved, and a scoped first engagement.
Talk through the aircraft, records, evidence, deadline, and next useful step.