Skip to content

ARP4761A display systems

ARP4761A safety-assessment evidence support for display systems

This support maps the safety-assessment evidence behind a cockpit display system to what ARP4761A expects a supplier to show. It is used by the display equipment team preparing a package for an FAA or EASA submittal, or answering a compliance finding on one already filed. The work reads the functional hazard assessment, the preliminary and system safety assessments, the failure-condition classifications, and how the display's DAL flows into the DO-178C software lifecycle data. You get a standards map keyed to the ARP4761A process objectives, a gap list ranked by what blocks the finding, and a sequence for closing each gap.

When this review is needed

  • A display package is being assembled for submittal and the team wants the safety-assessment evidence checked against ARP4761A first.
  • An authority raised a finding that the display's failure-condition classification is not substantiated by the safety assessment on file.
  • A misleading-information failure mode was identified late and its DAL allocation has to be reconciled with the software already coded.
  • A display function changed after the preliminary safety assessment was written and the derived requirements have drifted from the current design.

The problem

Display safety cases fail at the joints, not in the individual documents. The functional hazard assessment names a hazardously misleading indication as catastrophic, but the failure-condition classification in the system safety assessment reads it as major, and the software DAL was set from the lower number. Each artifact looks defensible alone. The break only shows when someone traces one failure condition from the hazard through the fault tree to the software level, and by then the code is written to the wrong assurance level.

What gets reviewed

What gets validated

  • Every failure condition in the hazard assessment carries a classification that the system safety assessment substantiates
  • The display DAL matches the most severe failure condition the item can contribute to, not an averaged one
  • Misleading-information hazards are analyzed as their own failure conditions rather than folded into loss of function
  • Derived requirements from the safety assessment appear in the display requirements baseline and trace to verification
  • Redundant display channels have a common-cause analysis that reflects shared power, data, and symbol-generation paths

Evidence normally required

Common discrepancies

  • A misleading-information failure condition classified below the level the hazard assessment implies
  • Display DAL set from a loss-of-function case while a more severe misleading case sits unaddressed
  • Derived safety requirements that never made it into the display requirements baseline
  • A shared symbol generator whose common-cause contribution to redundant displays is not analyzed

What is at stake

A display DAL set below what the failure condition demands means the software lifecycle data cannot support the classification the authority reads in the hazard assessment. The finding response then asks for either a re-justified classification or upgraded software evidence, and the second option can force verification rework across the whole item. Left unaddressed, the mismatch surfaces at the finding stage where the schedule has no slack left.

Move from findings to resolution

Identify gaps against the means of compliance.

How the work runs

01

Pull the failure conditions

Extract every display failure condition from the hazard assessment, including the misleading-information cases.

02

Trace classification to DAL

Follow each classification through the system safety assessment to the allocated DAL and the software level it drove.

03

Check independence and derived requirements

Verify redundant channels are truly independent and that derived safety requirements reached the display baseline.

04

Sequence the closure

Rank the gaps by what blocks the finding and identify which fix unblocks the most.

What the buyer receives

  • A standards map keyed to the ARP4761A process objectives for the display item
  • A gap list ranked by what blocks the finding or the submittal
  • A closure sequence identifying which artifact to fix first and what it unblocks

Who uses the output

  • Certification leads assembling the display package for submittal
  • Safety engineers reconciling failure-condition classifications with the software DAL
  • Compliance managers responding to an authority finding on the display safety case

How the work fits into the transaction or program

This review sits between the display safety assessment and the DO-178C software evidence, where the DAL is the hinge that connects them. It runs before submittal so the classification and the software level are reconciled on the supplier's schedule, and it feeds the compliance matrix that carries the display item into the type or supplemental approval.

Start with a single asset

Confirm requirements trace through verification.

Jurisdiction-specific considerations

FAA and EASA both accept ARP4761A as a means of showing the safety-assessment process, but they read the misleading-information failure condition differently on flight-critical displays. The map notes where a classification that satisfies one authority will draw a question from the other so the supplier is not surprised by a divergent finding.

Regulatory limits

This work maps and checks the safety-assessment evidence against ARP4761A. It does not make an airworthiness determination, set the failure-condition classification on an authority's behalf, or grant any approval. Those decisions rest with the applicant and the certifying authority.

What this review does not cover

Specific to this review

  • On displays, the misleading-information failure condition is usually more severe than loss of display, so a DAL set from the loss case is the classic under-allocation.
  • The DAL is where the safety assessment and the software evidence have to agree; a mismatch there is the most expensive break to fix because it reaches into verification.
  • A shared symbol generator or graphics engine feeding redundant displays defeats the independence the fault tree assumes unless its common-cause contribution is analyzed explicitly.

Sources

Frequently asked questions

Why does the display DAL keep coming up as the problem?

Because it is the single number that ties the safety assessment to the software evidence. If the failure condition is catastrophic but the DAL was set from a less severe case, the software lifecycle data cannot support the classification the authority reads, and reconciling that late means verification rework.

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.