PMA article data
Configuration management data support for a PMA article approval
Configuration management support gets the baseline, revision, and release evidence in a PMA article package into a state where a reviewer can trust that the data on the table describes one controlled configuration. It runs before formal review, for a supplier who has to show that every drawing, part number, and software or hardware load in the submittal belongs to the same baseline. The work walks the change history and release records and flags where the evidence describes a configuration other than the one being approved. You receive a gap assessment against the controlled baseline, an evidence map from each item to its release record, and a closure plan to reconcile the mismatches.
When this review is needed
- The part number and drawing revisions in the submittal do not all trace to a single released baseline.
- Software built to DO-178C or hardware built to DO-254 carries a load or version the release records do not pin down.
- A change was incorporated late and the release evidence still points at the prior configuration.
- The package is heading into formal review and the applicant wants the baseline proven before a reviewer tests it.
The problem
By the time a PMA article package is compiled, the design has moved through enough revisions that the evidence and the baseline no longer point at the same thing. A test report references a drawing revision that was later superseded, a software load in the analysis is not the load the release record names, and the part-number effectivity in one document contradicts another. Each item may be correct on its own, but a reviewer cannot tell which configuration the package is actually asking to approve.
What gets reviewed
- The controlled baseline identified and every submitted item checked against it
- Drawing and part-number revisions reconciled across test, analysis, and release records
- Software loads and hardware versions confirmed to match the DO-178C and DO-254 evidence
- The change history reviewed so incorporated changes are reflected in the released configuration
- Effectivity statements checked for agreement across the documents that carry them
- Superseded revisions identified so no two documents describe conflicting configurations
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 part number and revision in the package traces to a single released baseline
- Test and analysis reports reference the revision actually being submitted, not a superseded one
- Software load and hardware version identifiers match between the release records and the assurance evidence
- Each incorporated change appears in the released configuration with a corresponding record
- No two documents in the package assert conflicting effectivity for the same item
Evidence normally required
- The configuration baseline and the item list for the article
- Drawing, part-number, and revision records with their release history
- Software and hardware version records tied to the DO-178C and DO-254 evidence
- The change log covering revisions made during the program
- Test and analysis reports that reference specific configurations
Common discrepancies
- A test report tied to a drawing revision that a later change superseded
- A software load in the assurance evidence that the release record does not name
- An incorporated change with no release record placing it in the controlled baseline
- Conflicting part-number effectivity between two documents in the same package
What is at stake
A package that describes more than one configuration forces the reviewer to stop and ask which one is real, and the applicant then has to prove that the test, analysis, and release evidence all belong to the same baseline. If they do not, verification runs against a superseded revision have to be repeated, and the approval waits on a re-release of the affected data that could have been caught before submittal.
How the work runs
Fix the baseline
Identify the controlled configuration the package is asking to approve and its item list.
Reconcile the evidence
Check every drawing, part number, and load in the package against that baseline.
Walk the change history
Confirm each incorporated change reached the released configuration with a record behind it.
Close the mismatches
Order the re-releases and re-references needed so the package describes one configuration.
What the buyer receives
- A gap assessment listing every item that does not reconcile to the controlled baseline
- An evidence map tying each submitted item to its release record and revision
- A closure plan ordering the reconciliations and re-releases needed before submittal
Who uses the output
- Certification leads confirming the package describes one configuration a reviewer can trust
- Engineering owners deciding which revisions have to be re-released or re-referenced
- Quality leads verifying configuration control before the data package is signed out
How the work fits into the transaction or program
Configuration control is the ground the rest of the package stands on, because a compliance finding is only as good as the configuration it was made against. Reconciling the baseline before formal review means the applicant is not caught mid-review proving that a test ran on the right revision, and the reconciled baseline feeds every other evidence set, from the safety analyses to the conformity records, that has to name a configuration.
Start with a single asset
Reduce finding cycles by checking the package first.
Jurisdiction-specific considerations
The configuration data is prepared to the ARP4754B, DO-178C, and DO-254 practices the FAA expects for a PMA article, and the release records have to satisfy the applicant's own approved configuration control process. Where the article configuration is also destined for another authority, the review notes where baseline or effectivity conventions differ so the same evidence is not re-cut twice.
Regulatory limits
The review confirms the submitted evidence reconciles to a single controlled baseline. It does not approve a configuration, release any data on the applicant's behalf, or make an airworthiness determination about the article.
What this review does not cover
Specific to this review
- A compliance finding is meaningless if it was made against a revision the release records later superseded, so configuration reconciliation comes before any claim of compliance.
- Software and hardware load identifiers are the items most often out of step, because assurance evidence and release records are maintained by different teams on different clocks.
- Conflicting effectivity between two documents is harder to spot than a missing record, because each document reads as internally correct.
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.
SAE International. Development assurance process at aircraft and system level, including requirements capture and validation.
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).
Frequently asked questions
What if a test ran against a revision that was later changed?
The review flags it so you can decide whether the change affected what the test covered. If it did, that verification has to be repeated or shown still valid against the current revision. Finding it before submittal is far cheaper than having a reviewer find it mid-review.
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.