TSO authorization
Configuration management data support for TSO authorization
A TSO configuration management review confirms that the baselines, revisions, and release records identify the exact article the rest of the data package describes. Equipment suppliers use it before submission, so no report ends up describing a configuration the controlled records do not match. It checks that the submitted evidence ties to a controlled baseline, that the change history accounts for every revision behind that evidence, and that the release records name the configuration the article will actually ship as. You get a gap assessment on the configuration control, a map from each data item to the baseline it belongs to, and a closure plan for the records that do not reconcile.
When this review is needed
- The data package is being assembled and each report has to be tied to a controlled baseline before submission.
- Late design changes produced revisions that the submitted evidence may or may not reflect.
- Test and analysis were run against different revisions and the configuration behind each result has to be pinned.
- The release record for the article has to match the configuration the whole package describes.
The problem
A long program produces revisions faster than the evidence keeps up, so a test report can describe one configuration while the release record names another. Configuration management is the connective tissue under every other data item, and when it slips, each report is individually plausible but they no longer describe the same article. That divergence is invisible inside any single document and only shows when someone reconciles them against the controlled baseline.
What gets reviewed
- The controlled baselines and the revisions behind the submitted evidence
- Each data item tied to the specific configuration it was generated against
- The change history accounting for every revision the package relies on
- Release records naming the configuration the article will ship as
- Consistency of configuration identification across DO-178C, DO-254, and DO-160G data
- Records where the described configuration does not reconcile with the baseline
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 submitted report identifies the configuration it was generated against
- The change history accounts for each revision between test and release
- Software, hardware, and environmental data all reference the same controlled baseline
- The release record names the configuration the rest of the package describes
- No report characterizes a revision the change history does not contain
Evidence normally required
- The configuration management plan and the controlled baselines
- The change history and revision records for the article
- The release records for the software, hardware, and article
- The data reports whose configuration references need reconciling
- The configuration each test and analysis was run against
Common discrepancies
- A test report describing a revision the release record has superseded
- A revision relied on by the evidence that the change history does not record
- Software and hardware data referencing different baselines for the same article
- A release record naming a configuration the package as a whole does not describe
What is at stake
Evidence that does not tie to the controlled configuration undermines the whole package, because a reviewer cannot tell which article the data actually characterizes. A test run against a superseded revision may have to be repeated on the released configuration, and a release record that names the wrong baseline can invalidate compliance claims built on top of it. A mismatch found late forces reconciliation across every affected report at once.
How the work runs
Pin the baselines
Establish the controlled baselines and the revisions the submitted evidence relies on.
Tie evidence to configuration
Confirm each report identifies the configuration it was generated against.
Check the release records
Confirm the release records name the configuration the package as a whole describes.
Reconcile the exceptions
List records that do not reconcile and sequence the work to align them.
What the buyer receives
- A gap assessment on the configuration control across the package
- A map from each data item to the baseline it belongs to
- A closure plan for the records that do not reconcile to the baseline
Who uses the output
- Certification leads confirming the package describes one controlled article
- Configuration management owners closing revision and release discrepancies
- Program managers tracking which reconciliations still block submission
How the work fits into the transaction or program
Configuration management underpins every other data item, since each report is only meaningful against the configuration it describes. This review runs as the package is assembled, before submission, and its baseline map lets the compliance matrix and the release record rest on a package that describes a single controlled article.
Start with a single asset
Reduce finding cycles by checking the package first.
Jurisdiction-specific considerations
Baseline and release identification is organized to the FAA's expectations for the TSO article, so the controlled records follow FAA-accepted practice. The same configuration can support a program under another authority, but the review reconciles the records against the FAA basis rather than assuming another authority's identification scheme.
Regulatory limits
The review checks that the evidence reconciles to a controlled configuration and that the release records match the package. It does not control the configuration on the applicant's behalf, approve a baseline, or make a finding on the article's compliance.
What this review does not cover
Specific to this review
- Configuration slips are invisible inside any single report, because each one is internally consistent; the mismatch only appears when the reports are reconciled against the baseline.
- A program generates revisions faster than the evidence catches up, so the gap between test-time and release-time configuration is the recurring failure.
- A wrong baseline on the release record is the most costly discrepancy, because every compliance claim above it inherits the error.
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).
SAE International. Development assurance process at aircraft and system level, including requirements capture and validation.
Frequently asked questions
Why does configuration management matter to the compliance case?
Every test and analysis is only evidence for the configuration it was run against. If the package describes several configurations without saying so, a reviewer cannot tell which article the compliance claims cover, so the configuration reconciliation is what lets the rest of the data stand as one coherent case.
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.