PMA article data
Airborne software lifecycle data support for a PMA article approval package
This review examines the airborne software lifecycle data built to DO-178C for a PMA article, and tests whether the data set matches the assigned software level. A certification engineer checks that the plans, standards, verification records, configuration data, and accomplishment summary are all present at the objectives the level requires, and that they describe one coherent software effort. It catches lifecycle data that reflects a lower level than the software is assigned. You receive a gap assessment, an objective-coverage map at the assigned level, and a closure plan before the package enters formal review.
When this review is needed
- A DO-178C data set is assembled and the team wants its objective coverage checked against the assigned level.
- The software level was set by the safety assessment and the data must demonstrate every objective it demands.
- Reused or third-party software carries lifecycle data whose level and completeness need confirming.
- The data feeds the accomplishment summary and must be coherent before the summary claims objectives met.
The problem
DO-178C data accumulates across a long lifecycle, and the objectives that apply depend entirely on the software level, which is easy to lose track of. A component developed to one level gets reused where a higher level is now required, verification records cover structural coverage at the old target, and the plans describe a process the actual records do not fully follow. The data set can look thorough while missing the specific objectives the assigned level adds, and those gaps only appear when the data is read objective by objective against the level.
What gets reviewed
- Plans and standards checked for the objectives the assigned software level requires
- Verification records confirmed to meet the level's coverage and independence expectations
- Configuration management and quality assurance data checked for completeness
- Reused or third-party software data assessed against the level it must now meet
- The accomplishment summary reconciled with the lifecycle records it rests on
- Objective gaps between the delivered data and the assigned level flagged
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
- Every DO-178C objective for the assigned level is addressed by lifecycle data
- Verification records meet the coverage and independence the level requires
- Configuration and quality data are present and consistent across the lifecycle
- Reused software carries data adequate for the level it is now used at
- The accomplishment summary matches the records rather than the intended plan
Evidence normally required
- The DO-178C plans, standards, and their current revisions
- Verification results, review records, and coverage analysis data
- Configuration management and quality assurance records
- The assigned software level and the safety assessment that set it
- Lifecycle data for any reused or third-party software components
Common discrepancies
- Lifecycle data reflecting a lower software level than the one assigned
- Verification coverage that stops short of the assigned level's target
- Reused software carried at its original level without upgrade to the current need
- Plans describing a process the actual verification records do not follow
What is at stake
Software lifecycle data that falls short of its assigned level is a finding the FAA will not waive, because the level was set by the safety assessment for a reason. Closing it late can mean rerunning verification to hit coverage targets, reconstructing configuration records, or requalifying reused software, all under review pressure. A summary that claimed objectives met on this data inherits every gap the moment the underlying records are sampled.
How the work runs
Fix the assigned level
Confirm the software level set by the safety assessment, since it determines which objectives apply.
Check objective coverage
Read the lifecycle data objective by objective against the assigned level and note every gap.
Reconcile reuse and summary
Assess reused software against the current level and confirm the summary matches the records.
Deliver the map and plan
Provide an objective-coverage map and a closure plan for the work each gap requires.
What the buyer receives
- A gap assessment listing objectives unmet for the assigned software level
- An objective-coverage map showing where the data meets or misses the level
- A closure plan for the verification, configuration, or requalification work needed
Who uses the output
- Certification leads asserting software objective coverage at review
- Quality leads confirming configuration and quality records are complete
- Software leads closing the coverage and process gaps identified
How the work fits into the transaction or program
The software lifecycle data is the substance the accomplishment summary summarizes, so it is checked before the summary claims objectives met. Confirming objective coverage against the assigned level early prevents the summary and the compliance matrix from resting on software data that a reviewer's sampling would expose as short.
Start with a single asset
Reduce finding cycles by checking the package first.
Jurisdiction-specific considerations
This work supports PMA approval under the FAA framework, where DO-178C is the recognized means for airborne software development assurance. The review keeps the objective-coverage argument in FAA terms and does not recast it for another authority's software process.
Regulatory limits
This review assesses whether the lifecycle data meets the assigned software level. It does not develop or verify software, does not make a compliance finding, and does not grant PMA or any airworthiness approval.
What this review does not cover
- Producing missing verification, coverage, or configuration records
- Performing the safety assessment that assigns the software level
- Requalifying reused or third-party software on the supplier's behalf
Specific to this review
- DO-178C objectives are level-driven, so the same data set can be complete at one level and short at the next, which makes the assigned level the reference point for every check.
- Reused software is the most common shortfall: it carries the level it was built to, not the level the new use requires.
- Structural coverage is where under-leveled data shows first, because the coverage target rises with the assigned level.
- A tidy set of plans can mask a process the records did not follow, so plans and actual verification evidence must be read together.
Sources
U.S. Government (eCFR). Type certificates, STCs (Subpart E), TSO authorizations (Subpart O), PMA (Subpart K), and export airworthiness approvals (Subpart L).
Federal Aviation Administration. FAA type certification process, certification basis establishment, and compliance findings.
RTCA. Objectives and lifecycle data for airborne software assurance, by design assurance level (DAL A-E).
SAE International. Development assurance process at aircraft and system level, including requirements capture and validation.
Frequently asked questions
Our software was developed to a lower level on a previous product. Can we reuse it?
Reuse is possible, but the lifecycle data has to meet the level the new application requires, not the level it was originally built to. The review compares the existing data against the assigned level objective by objective and identifies exactly what verification, coverage, or configuration work is needed to close the gap before the data is relied on.
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.