Certification evidence

Software configuration index evidence review for DO-178C

This review is for avionics suppliers, equipment suppliers, Certification teams responsible for software configuration index. It is triggered by final software build release. EE checks SCI contents against released source, executable object code, part numbers, plus the governing plan or application, against DO-178C. Discrepancies include missing source records, mismatched configuration, unsupported assumptions, or compiler or linker versions in the SECI that differ from the environment that produced the release. Output includes Software configuration index exception register, Claim to evidence map, Reviewer question list.

When this review is needed

Submittal planning has reached the software configuration index evidence package.
A reviewer has questioned one cited claim or missing source record.
A change to configuration, installation, or intended use may affect prior evidence.
The program needs an exception list before formal review.

The problem

The hard part is proving do the Software Configuration Index and Software Life Cycle Environment Configuration Index identify exactly one reproducible build with records that match the reviewed configuration. A tidy index still fails if compiler or linker versions in the SECI that differ from the environment that produced the release or if the cited record belongs to another baseline.

What gets reviewed

Review sCI contents against released source against the configuration, installation, or claim under review.
Compare executable object code against the configuration, installation, or claim under review.
Trace part numbers against the configuration, installation, or claim under review.
Challenge media identification against the configuration, installation, or claim under review.
Reconcile load instructions against the configuration, installation, or claim under review.
Confirm archive records against the configuration, installation, or claim under review.

What gets validated

Pass check: sCI contents against released source must match the released configuration and the claimed means of compliance.
Configuration check: executable object code must match the released configuration and the claimed means of compliance.
Trace check: part numbers must match the released configuration and the claimed means of compliance.
Rationale check: media identification must match the released configuration and the claimed means of compliance.
Closure check: load instructions must match the released configuration and the claimed means of compliance.

Evidence normally required

Controlled sCI contents against released source
Released executable object code
Signed part numbers
Current media identification
Archived load instructions
Supplier archive records

Common discrepancies

Gap: compiler or linker versions in the SECI that differ from the environment that produced the release.
Mismatch: sCI listing source baselines that no archive can reproduce.
Unsupported claim: load part numbers that do not match conformity paperwork.

What is at stake

Late discovery can reopen tests, analysis, or plan wording after schedules have already assumed closure. The worst cases involve SCI listing source baselines that no archive can reproduce because they need technical support, not cleaner prose.

Move from findings to resolution

Identify gaps against the means of compliance.

How the work runs

Frame Software Configuration

Confirm the exact event, affected file set, buyer role, and decision standard before any sci contents against released source is treated as sufficient.

Trace Review Evidence

Walk the named evidence from index entry to source artifact and mark where the trail supports, conflicts with, or fails to answer the page-specific question.

Sort Certification Sci

Group exceptions by closure route: document retrieval, data correction, engineering disposition, authority response, or contractual decision.

Package Prove Certified

Deliver the exception list, evidence map, and owner sequence in a form that can move directly into remediation, submittal cleanup, or transaction negotiation.

What the buyer receives

Software configuration index exception register
Claim to evidence map
Reviewer question list
Closure action plan

Who uses the output

configuration manager assign closure actions from the exception register.
software lead use the map to locate source evidence.
quality manager decide what can proceed and what must wait.

How the work fits into the transaction or program

Do the Software Configuration Index and Software Life Cycle Environment Configuration Index identify exactly one reproducible build. The evidence set centers on SCI contents against released source and executable object code, part numbers and media identification, build and load instructions, archive records, and SECI tool and compiler versions against actual build logs. The likely weak points are compiler or linker versions in the SECI that differ from the environment that produced the release, SCI listing source baselines that no archive can reproduce, and load part numbers that do not match conformity paperwork. The output gives the configuration manager a cleanup register for Software configuration index before final software build release.

Start with a single asset

Confirm requirements trace through verification.

Regulatory limits

EE organizes evidence and exceptions; it does not approve data, make compliance findings, determine airworthiness, or replace the applicant, designee, design organization, or authority.

What this review does not cover

Regulatory approval or acceptance
Design ownership or finding signature
Physical conformity inspection
Laboratory testing or manufacturing

Specific to this review

Configuration identity matters because evidence from another baseline may prove a different article, load, or installation.
A useful trail names the source record, revision, owner, and closure decision for each claim.
The exception list separates document-control cleanup from gaps that need engineering substantiation.
The finding pattern for this page is specific: compiler or linker versions in the SECI that differ from the environment that produced the release changes the strength of the certification argument.
The scope uses the Software Configuration Index Review question as the control point, so the review stays tied to Final software build release and the buyer decision behind it.
The evidence starts with SCI contents against released source and follows Evidence 178c Certification Sci references until every exception has a source location and a reason code.
The finding logic separates missing paperwork, conflicting status, stale revision data, and unsupported disposition because each class closes through a different owner.
The timing matters for configuration manager: the output is useful only if the unresolved items are visible before acceptance, submittal, handback, or negotiation pressure fixes the sequence.
The boundary control keeps Seci Prove Certified Build questions in the records or certification lane and sends technical acceptance issues to the authorized people who own them.
The handoff value comes from Software configuration index exception register; it gives the next reviewer a precise map instead of another broad request for a better file.

Sources

DO-178C - Software Considerations in Airborne Systems and Equipment Certification

RTCA. Objectives and lifecycle data for airborne software assurance, by design assurance level (DAL A-E).

Frequently asked questions

What makes this evidence review different from a general file audit?

The scope is tied to software configuration index review and to the decision named in the request. A general audit can list weak records; this pass ranks the gaps by whether they block final software build release or can be closed later without changing the decision.

What evidence has to be available before this work starts?

The starting point is sci contents against released source, the current status source, and any index or matrix that tells reviewers where the supporting artifact should live. Missing inputs are logged as findings rather than filled with assumptions.

Who decides whether an open item is acceptable?

The review explains what the evidence supports and gives configuration manager a closure path. Acceptance remains with the buyer, operator, authority, delegated engineer, or authorized person responsible for the underlying airworthiness or certification decision.

Relevant glossary terms

Configuration Items and Software Lifecycle Data Software Baselines Software Accomplishment Summary (SAS)Software Item Problem Reports and Change Requests

Single event effects analysis review for see finding or issue paper raisedSingle event effects analysis review for avionics suppliers and equipment suppliers. EE checks source evidence Software service history credit evidence review for DO-178CChecking software service history credit? EE reviews service period definition against DO-178C and returns gap Configuration-management evidence review for avionics and equipment suppliersIf your baselines cannot name the exact build the certification data describes, submittal stalls. Get a reconc Software Accomplishment Summary (SAS) reviewThe SAS must report what the program did, not what the PSAC promised. We check every claim against the DO-178C Certification record validation for approved articlesRecords that drift from the approved configuration surface at audit or transfer. We inventory the file and map

Where this fits

Service: TSO and STC Certification For Equipment

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.

Book a call