Software level mapping
Software level objective mapping under DO-178C
Software level objective mapping confirms that the DO-178C objective set a program commits to, including which objectives require independence, matches the software level the safety assessment assigned. It is used by teams whose plans were written before the level settled, leaving the committed objective set heavier or lighter than the level demands. The work lays the objective set side by side with the assigned level and the lifecycle data already produced. You receive an objective-to-level map and a list of the objectives the data does not yet answer.
When this review is needed
- The assigned software level settled after the plans were written and the committed objective set has to be reconciled against it.
- A function moved in the architecture, changing its level, and the objective set has to follow before the data is judged against the old one.
- Independence was promised in the plans and the team needs to confirm the objectives requiring it are actually being met that way.
- A tool was relied on to discharge an objective and its qualification level has to match the credit being taken.
The problem
DO-178C scales the work by software level: the table of objectives, and the subset that demand independent review, grows as the level rises. Plans are written early, when the safety assessment may still move a function up or down a level. Once the level shifts, the objective set the plans committed to drifts from the set the level now requires, and the lifecycle data keeps being judged against the wrong target until someone lays them side by side.
What gets reviewed
- The assigned software level and the objective set DO-178C tables tie to it
- Which of those objectives require independence at that level
- The objective set the plans and standards actually committed to
- The lifecycle data on hand mapped to the objectives it is meant to satisfy
- Tool qualification credit and whether the tool level matches the credit taken
- Objectives the level requires that the data does not yet answer
What gets validated
- The committed objective set matches the table for the assigned software level
- Each objective marked for independence at the level is met with the independence required
- Each objective maps to the lifecycle data item meant to satisfy it
- Tool qualification level supports the objective credit the program takes from the tool
- A level change since the plans were written is reflected in the objective set used
- Objectives with no supporting data are identified and flagged for closure
Evidence normally required
- The assigned software level and the safety assessment that drove it
- The PSAC and the rest of the software plans and standards
- The lifecycle data produced so far and its current traceability
- Any tool qualification data the program relies on
- Any record of a level change during the program
Common discrepancies
- An objective set sized for a level below the one the safety assessment now assigns
- Independence claimed in the plans but not reflected in how objectives are actually met
- Tool credit taken at an objective the tool's qualification level does not support
- Required objectives with no lifecycle data mapped to them at all
- A level change that updated the basis but never updated the committed objective set
What is at stake
An objective set sized below the assigned level leaves work undone that an audit will find, often late, when the verification effort to close it is hardest to absorb. An objective set sized above the level spends review and independence effort the level never required. Either way, the stage-of-involvement audit reads the mismatch directly off the plans.
Move from findings to resolution
Identify gaps against the means of compliance.
How the work runs
Fix the level
Confirm the assigned software level and the objective table DO-178C ties to it.
Read the plans
Pull the objective set and independence claims the PSAC and plans actually committed to.
Map the data
Tie each objective, and each independence and tool credit, to the lifecycle data meant to satisfy it.
Flag the gaps
List the objectives the level requires that the data does not yet answer, ready for audit.
What the buyer receives
- An objective-to-level map for the assigned software level
- An independence view showing which objectives need it and whether they have it
- A tool qualification check against the objective credit taken
- A list of objectives the lifecycle data does not yet answer
Who uses the output
- Software certification leads preparing for stage-of-involvement audits
- Verification engineers closing the objectives the data does not answer
- Program management sizing the remaining objective work against the level
How the work fits into the transaction or program
The work reconciles the software objective set with the level the system allocation produced. It pairs with development-assurance level allocation when the level itself is what moved, and with hardware level mapping when the same function spans software and complex hardware.
Start with a single asset
Confirm requirements trace through verification.
Regulatory limits
Endeavor Elements maps the applicant's objective set and lifecycle data to the assigned software level. It does not assign the level, make compliance findings for the authority, or determine that the software is approved.
What this review does not cover
- Assigning the software level on the authority's behalf
- Producing the missing lifecycle data or verification evidence
- Making official compliance findings or issuing any approval
Specific to this review
- DO-178C scales its objective set by software level, and the count of objectives requiring independence rises sharply at the higher levels.
- A level can change after the plans are fixed, so the committed objective set and the assigned level drift apart quietly until they are mapped together.
- Objective credit can be taken from a development or verification tool, but only at the tool qualification level DO-330 ties to that credit.
Sources
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.
U.S. Government (eCFR). Type certificates, STCs (Subpart E), TSO authorizations (Subpart O), PMA (Subpart K), and export airworthiness approvals (Subpart L).
Frequently asked questions
What happens to the objective set when a function changes level?
The objective set and its independence requirements follow the new level, not the level the plans assumed. The mapping re-reads the committed set against the current level so the data is judged against the right target before an audit does it for you.
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.