Software planning evidence
Plan for Software Aspects of Certification (PSAC) review
A PSAC review checks that an article's Plan for Software Aspects of Certification holds together before the authority sees it: that the assigned software level, the planned lifecycle data, the standards, and the supplier verification approach are stated, internally consistent, and aligned with the DO-178C objectives the level demands. It is used by avionics and equipment suppliers at the start of a software program. You receive a marked-up plan and a list of the commitments that are missing, vague, or inconsistent with the rest of the plan set.
When this review is needed
- A new software program is starting and the plan needs an independent read before the authority is asked to agree to it.
- The software level changed after the safety assessment and the plan has to be reconciled with the new objectives.
- Reused or commercial-off-the-shelf software is in scope and the plan has to state how credit will be claimed.
- A program was inherited mid-stream and the team wants to know whether the existing plan still describes what is being built.
The problem
The PSAC sets the terms the rest of the software program is judged against, yet it is often written once and left behind as the design moves. When the plan names a software level that no longer matches the safety assessment, or commits to lifecycle data the team is not actually producing, the gap surfaces during a stage-of-involvement review rather than at the desk where it could have been fixed cheaply.
What gets reviewed
- The assigned software level and its consistency with the safety assessment
- The lifecycle data the plan commits to produce and the objectives each item covers
- The standards the plan invokes and how the supplier verification approach is described
- Reuse, commercial-off-the-shelf, and previously developed software credit claims
- Consistency between the PSAC and the companion plans for development, verification, and configuration management
- Transition criteria between lifecycle phases and the entry conditions each phase declares
What gets validated
- The software level stated in the plan matches the level assigned by the safety assessment
- Each DO-178C objective expected at the assigned level maps to planned lifecycle data
- Reuse and commercial-off-the-shelf credit claims state the basis on which credit is sought
- Transition criteria between lifecycle phases are defined rather than implied
- The PSAC and the other software plans describe the same program without contradiction
- Verification independence is described where the assigned level requires it explicitly
Evidence normally required
- The current PSAC draft
- The safety assessment output that drives the software level
- The companion software development, verification, and configuration management plans
- Any prior authority correspondence or plan agreement notes
Common discrepancies
- A software level in the plan that no longer matches the safety assessment
- Objectives the level requires that have no planned lifecycle data behind them
- Credit for reused or off-the-shelf software asserted without a stated basis
- Verification independence described loosely where the level expects it explicitly
- Plan set members that contradict each other on tooling or transition criteria
What is at stake
A plan the authority will not agree to stalls the program before development objectives can be credited. Rework on the plan ripples into the verification approach and the supplier oversight terms, and the schedule absorbs the cost.
Move from findings to resolution
Identify gaps against the means of compliance.
How the work runs
Confirm the level
Trace the software level in the plan back to the safety assessment that assigned it and flag any mismatch.
Map objectives to data
Check that each DO-178C objective expected at the level has planned lifecycle data committed against it.
Cross-check the plan set
Compare the PSAC against the development, verification, and configuration management plans for contradictions.
Mark up and prioritize
Return the annotated plan with a remediation note ordered by likely review impact.
What the buyer receives
- A marked-up PSAC with each gap flagged against the relevant objective
- A list of plan commitments that are missing, vague, or inconsistent
- A short remediation note ordered by likely review impact
Who uses the output
- Certification leads taking the plan into authority agreement
- Software engineering leads adjusting the lifecycle data commitments
- Program management aligning the companion plans before the program scales
How the work fits into the transaction or program
The review steadies the plan the authority agrees to first, so the objectives credited later rest on a stable foundation. It pairs with a Software Accomplishment Summary review at the other end of the program, when the plan is checked against what the program actually delivered.
Start with a single asset
Confirm requirements trace through verification.
Regulatory limits
The review checks the applicant's plan for consistency and DO-178C alignment. It does not agree the plan on the authority's behalf, make compliance findings, or guarantee that the authority will accept the software level or the credit claims the plan asserts.
What this review does not cover
- Agreeing the plan or making findings on the authority's behalf
- Assigning the software level or performing the safety assessment
- Writing the lifecycle data the plan commits to produce
Specific to this review
- The PSAC is the artifact the authority agrees to first; an unstable plan undermines every objective claimed later.
- Software level drift after the safety assessment is a recurring cause of late plan rework, because the plan is rarely re-read when the level changes.
- Reuse and commercial-off-the-shelf claims that omit the basis for credit are flagged during plan review rather than at submittal.
- A PSAC commits the supplier to a fixed set of lifecycle data; planning to produce less than the level requires is visible at the desk long before a stage-of-involvement review.
Sources
RTCA. Objectives and lifecycle data for airborne software assurance, by design assurance level (DAL A-E).
U.S. Government (eCFR). Type certificates, STCs (Subpart E), TSO authorizations (Subpart O), PMA (Subpart K), and export airworthiness approvals (Subpart L).
SAE International. Safety assessment methods (FHA, PSSA, SSA, FTA, FMEA) supporting development assurance level assignment.
Frequently asked questions
Does the review get the PSAC agreed by the authority?
No. The authority agrees the plan. The review checks the plan for internal consistency and DO-178C alignment so the team takes a stable plan into that agreement.
Can you review a plan for software with reuse or commercial-off-the-shelf credit?
Yes. The review checks that each credit claim states the basis on which credit is sought, which is a common gap when reused or off-the-shelf software is in scope.
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.
Walk through your situation with an engineer who has done this work.