ARP4754B development-assurance support at the system level

When this review is needed

• A system is approaching a development-assurance review and the requirements validation evidence has to be checked against the assurance level claimed.
• DALs were assigned early and the architecture has since changed, so the allocation and any DAL reduction no longer match the design.
• The system requirements have grown but the validation, the proof that the requirements are correct and complete, has not kept pace.
• The link between the system requirements and the DO-178C and DO-254 evidence below them has frayed and needs to be re-established.
• A supplier wants an independent read of the system-level development assurance before it feeds a wider certification submittal.

The problem

ARP4754B sits above the software and hardware standards and is where the requirements either hold together or fall apart. Development assurance levels get assigned from the safety assessment, allocated across the architecture, and sometimes reduced by independence, but the reasoning behind the allocation is rarely written down well enough to survive review. Validation, showing that the requirements themselves are right, lags behind verification, showing the implementation meets them, so a program can have heavy verification evidence sitting under requirements no one confirmed were correct.

What gets reviewed

• The system development plan and the development assurance process it commits to
• System requirements capture and the validation that shows they are correct and complete
• The architecture and how development assurance levels are allocated across it
• Any DAL reduction by architecture or independence and the rationale behind it
• Bidirectional traceability from system requirements down to software and hardware items
• The link to the safety assessment that drives the DAL assignment
• System-level verification and the integration evidence that closes it

What gets validated

• Development assurance levels trace from the safety assessment to each system function and item
• Any DAL reduction by architecture or independence carries a documented and defensible rationale
• System requirements are validated for correctness and completeness, not only verified against
• Requirements trace bidirectionally to the DO-178C and DO-254 evidence that implements them
• Derived system requirements are captured and fed back into the safety assessment
• The architecture as built matches the architecture the DAL allocation assumed
• Integration and system-level verification evidence closes the requirements it claims to

Evidence normally required

• The system development plan and the development assurance process description
• The system requirements and any validation evidence assembled so far
• The architecture description and the DAL allocation and reduction rationale
• The traceability linking system requirements to software and hardware items
• The safety assessment that drove the development assurance level assignment
• System-level verification and integration evidence to date

Common discrepancies

• DAL reductions claimed by independence with no rationale that survives examination
• System requirements verified against but never validated for correctness or completeness
• An architecture as built that no longer matches the allocation the DALs assumed
• Derived system requirements that never returned to the safety assessment that should bound them
• Broken traceability between system requirements and the software and hardware evidence below
• DAL assignments inconsistent with the failure-condition classification the safety assessment set
• Integration evidence that closes only part of the requirements it is credited against

What is at stake

When the DAL allocation cannot be justified, the assurance claimed for the software and hardware below it is called into question, and the program reopens decisions that drove months of work. Requirements that were never validated can surface late as incorrect or incomplete, forcing redesign at the system level where the change ripples into every item beneath it and lands hard on the certification schedule.

How the work runs

What the buyer receives

• A development-assurance gap assessment against the assigned levels
• A requirements validation and DAL allocation view tied to the architecture
• A traceability view linking system requirements to software and hardware evidence
• A prioritized list of the system-level evidence to close before review

Who uses the output

• Certification leads preparing the system-level submittal or review
• Systems engineering teams closing validation and allocation gaps
• Program management sequencing the system, software, and hardware work together

How the work fits into the transaction or program

The support strengthens the system-level development assurance that the DO-178C and DO-254 work hangs from, so the allocation holds up when an examiner traces it. It pairs naturally with safety-assessment support, since the DALs come from there, and with the software and hardware compliance work that implements the requirements.

Aircraft-specific considerations

Development assurance levels follow the failure-condition classification of each function, so the same architecture can carry very different DALs across a system. A function whose failure is catastrophic drives the highest assurance and constrains how far any reduction by independence can go, while a function with minor effect carries a much lighter level, so the allocation has to be argued function by function rather than applied uniformly across the system.

Regulatory limits

Endeavor Elements supports the applicant's system-level development assurance data. It does not act as the authority or a delegate, make compliance findings, issue any approval, or guarantee acceptance. The applicant and the authority keep their roles, and the assignment and allocation of development assurance levels remain the applicant's, driven by the safety assessment.

What this review does not cover

• Making official compliance findings or acting as the authority or its delegate
• Issuing any approval, authorization, or design approval
• Performing the system design or the underlying software and hardware development itself

Specific to this review

• ARP4754B operates at the aircraft and system level and feeds the item-level assurance that DO-178C and DO-254 carry, so a weak DAL allocation undermines the evidence beneath it.
• Validation under ARP4754B is about whether the requirements are correct and complete, which is distinct from verification, and the two are routinely conflated in stalled programs.
• Development assurance levels can be reduced through architecture and independence, but the reduction stands or falls on a documented rationale that a reviewer can follow.
• Derived system requirements have no parent requirement, so they must be fed back into the safety assessment to confirm they introduce no new hazard.

Sources

Frequently asked questions

Relevant glossary terms

Related pages

Where this fits