Type-design packages
DO-178C software lifecycle data support for a type-design package
This review reads the DO-178C software lifecycle data in a type-design data package and checks it against the software level assigned to the function. It confirms the plans, standards, verification records, and accomplishment summary are present, consistent with each other, and satisfy the objectives that level demands. A certification engineer runs it so the software data set does not claim a level its evidence does not support. You get an objectives-coverage assessment against the assigned DAL, a list of missing or inconsistent lifecycle data, and a plan to close the gaps before submission.
When this review is needed
- Software development is complete and the applicant needs the lifecycle data checked against its assigned level.
- The software level was raised during the project and the existing data may not meet the higher objectives.
- The accomplishment summary is being assembled and its claims need to reconcile with the underlying records.
- A reviewer will read the software data against DO-178C objectives and the applicant wants gaps found first.
The problem
DO-178C data is voluminous and built by different people at different times, and the plans written at the start rarely match the records produced at the end. A verification record satisfies an objective in principle but was not run to the standard the plan set, or the accomplishment summary claims objectives the records do not support. The assigned software level sets which objectives apply, and a data set built loosely against a lower level does not lift cleanly when the level rises.
What gets reviewed
- The plans, standards, and lifecycle records checked for presence against the assigned software level
- Verification records checked to satisfy the objectives that level requires
- The accomplishment summary reconciled against the underlying lifecycle data
- Independence and coverage expectations checked where the level demands them
- Consistency between plans, standards, and the records produced against them
- Problem reports and open items assessed for their effect on the objectives claimed complete
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 objective applicable to the assigned software level maps to lifecycle data that satisfies it
- Verification records match the methods and coverage the plans and level require
- The accomplishment summary's claims are each supported by a record in the data set
- Independence is shown where the assigned level requires it
- Open problem reports do not undercut any objective marked satisfied
Evidence normally required
- The software plans, including the PSAC and verification and configuration plans
- The software development and verification standards
- The verification records and results for the software
- The software accomplishment summary and configuration index
- The problem report log and its current disposition
Common discrepancies
- Verification records that address an objective but not to the coverage the level requires
- An accomplishment summary claiming objectives the underlying records do not support
- Independence not shown for objectives where the assigned level requires it
- Plans and records that describe different processes for the same activity
What is at stake
Software lifecycle data that does not meet its assigned level draws findings that are slow to close, because closing them often means rerunning verification or reworking records to a standard that should have applied from the start. An accomplishment summary that overstates coverage is worse than a gap, since it commits the applicant to claims the reviewer will test against the records. Either way the software data becomes the schedule pole for the whole package.
How the work runs
Fix the level
Confirm the assigned software level and the objectives that follow from it.
Map objectives to data
Check that each applicable objective has lifecycle data that satisfies it at the right coverage.
Reconcile the summary
Test the accomplishment summary's claims against the underlying records and problem reports.
Order the closures
Sequence the gaps, flagging rework or re-verification so it starts first.
What the buyer receives
- An objectives-coverage assessment against the assigned software level
- A gap list of missing, inconsistent, or under-covered lifecycle data
- A closure plan ordering the gaps, with rework and re-verification flagged early
Who uses the output
- Certification leads who present the software data and answer for the PSAC
- Software and verification engineers who close the objective gaps
- Configuration managers who keep the accomplishment summary aligned with the records
How the work fits into the transaction or program
The software lifecycle data is one discipline's evidence under the compliance map, and it must satisfy the objectives set by the software level the system safety assessment assigned. This review confirms the data meets that level before it is offered as compliance evidence, so it holds when a reviewer reads it against DO-178C. It follows the safety assessment that sets the level and feeds the compliance map.
Start with a single asset
Reduce finding cycles by checking the package first.
Jurisdiction-specific considerations
FAA and EASA both accept DO-178C, but the PSAC is agreed with the authority and the accepted means can differ in detail between jurisdictions, particularly around tool qualification and alternative methods. The review reads the data against the PSAC agreed for the target authority rather than a generic reading of the standard.
Regulatory limits
This work checks whether the software lifecycle data satisfies the objectives for its assigned level. It does not develop or verify software, does not make a compliance finding, and does not determine airworthiness or grant approval. Those remain with the applicant and the authority.
What this review does not cover
- Performing software development or verification activities
- Writing or revising the PSAC or accomplishment summary
- Making the compliance finding for the software
Specific to this review
- The assigned software level, not the code, sets which objectives apply, so the same software can be short of evidence purely because its level rose during the project.
- An accomplishment summary that overstates coverage is more damaging than a plain gap, because the reviewer tests each claim against the records.
- Independence is a common late finding, since it is a process property that cannot be added after the fact without rerunning the activity.
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.
European Union / EASA. EASA design and production certification, STCs, ETSO authorizations, and EASA Form 1 release.
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
What happens to our software data if the assigned level changes?
A higher level brings more objectives and stronger independence and coverage expectations. Data built to a lower level does not automatically satisfy them, so the set has to be reassessed against the new level. This review shows exactly which objectives the current data no longer meets.
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.