ARP4754B navigation
ARP4754B development assurance evidence review for navigation equipment
This review examines a navigation equipment package against ARP4754B and reports where the development-assurance chain does not hold together. It is meant for the supplier's certification team, run before submittal or in response to a reviewer question. It looks at how sensor inputs, navigation database handling, and the software level assigned to the function are captured as requirements and verified against them. What you receive is a standards map, a list of the objectives left unanswered, and a practical order for closing them.
When this review is needed
- A navigation equipment package is heading for submittal and the supplier wants the ARP4754B gaps identified while there is still time to close them.
- The software level claimed for a navigation function is being questioned against the performance it has to meet.
- Navigation database currency and integrity requirements were assumed rather than captured, and a reviewer has noticed.
- A finding response depends on knowing which sensor-input assumptions have validation evidence behind them.
The problem
Navigation equipment lives on assumptions about the quality of its sensor inputs and the currency of its database, and those assumptions rarely make it into the requirement set as ARP4754B expects. The performance work may be solid while the trace from an aircraft-level navigation requirement down to the function's behavior is fragmentary. When the software level rests on a safety allocation that was never written down, the supplier is defending a number rather than a documented decision.
What gets reviewed
- Sensor-input requirements and the assumptions the navigation function makes about their quality
- Navigation database currency and integrity requirements captured and verified
- The software level assigned to the function and the safety allocation behind it
- Requirement trace from aircraft-level navigation objectives to equipment behavior
- DO-160G qualification aligned to the installation the requirements assume
- The DO-178C lifecycle data referenced for the software at the claimed level
What gets validated
- Each sensor-input assumption the navigation function relies on is captured as a validated requirement
- Database currency and integrity handling is specified and verified, not left to operational assumption
- The claimed software level follows from a recorded safety allocation for the function
- The trace from aircraft-level navigation requirements reaches the equipment behavior without a break
- DO-160G categories match the electromagnetic and installation environment the function assumes
Evidence normally required
- The navigation equipment certification plan with its ARP4754B objectives
- Sensor-input and database requirement sets with validation records
- The safety allocation supporting the assigned software level
- DO-160G qualification reports for the equipment
- DO-178C lifecycle data references for the navigation software
Common discrepancies
- A sensor-input quality assumption the function depends on but never states as a requirement
- Database currency handling verified in operation but absent from the requirement set
- A software level asserted without the safety allocation that would support it
- A gap in the trace between aircraft-level navigation requirements and the equipment logic
What is at stake
Unstated input assumptions turn into findings that force the supplier to reconstruct the reasoning after the fact, often under a schedule that no longer has slack. A software level that cannot be justified from the file can be challenged upward, which pulls otherwise-complete lifecycle data back into rework.
Move from findings to resolution
Identify gaps against the means of compliance.
How the work runs
Fix the input boundary
Identify every sensor-input and database assumption the navigation function depends on and check whether each is a stated requirement.
Confirm the software level basis
Trace the assigned software level back to the safety allocation that should justify it.
Walk the requirement trace
Follow the chain from aircraft-level navigation objectives to equipment behavior and mark the breaks.
Order the closures
Sequence the gaps so input and allocation work lands before the trace built on top of it.
What the buyer receives
- A standards map lining each ARP4754B objective up with the navigation evidence that answers it
- A list of unanswered objectives with the missing artifact named for each
- A closure order that resolves the input-assumption gaps before the trace work above them
Who uses the output
- Certification engineers preparing the navigation submittal
- Engineering leads defending the software level against a challenge
- Compliance managers tracking objective closure ahead of a finding response
How the work fits into the transaction or program
The review comes before submittal or after a first reviewer question, giving the navigation team a factual view of which ARP4754B objectives their evidence answers. Its closure order feeds directly into the certification plan so the schedule reflects the real state of the input and trace evidence.
Start with a single asset
Confirm requirements trace through verification.
Jurisdiction-specific considerations
FAA and EASA can weight database and sensor-integrity expectations differently for a navigation function, and the performance standards each references may not map one to one. The review flags where an evidence set that satisfies one authority may need supplementing for the other.
Regulatory limits
The review maps evidence to ARP4754B objectives and identifies gaps. It does not set a software level on the authority's behalf, agree a compliance finding, or determine that the equipment is airworthy.
What this review does not cover
- Writing the missing sensor-input or database requirements
- Running DO-160G qualification or DO-178C lifecycle activities
- Agreeing the software level with the certifying authority
Specific to this review
- Navigation functions fail ARP4754B trace most often at the input boundary, because the quality of a sensor feed is treated as a given rather than a stated, validated requirement.
- Database currency and integrity are operational realities that suppliers frequently forget to express as design requirements, so they never get validation evidence.
- A software level challenged upward on a navigation function can invalidate lifecycle data that was otherwise finished, which is why the safety allocation behind the level is checked first.
Sources
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).
Federal Aviation Administration. FAA type certification process, certification basis establishment, and compliance findings.
Frequently asked questions
Our software lifecycle data is complete. Why does the review still flag the software level?
Complete lifecycle data proves the software was built to a level. The review checks whether that level is the right one, which depends on the safety allocation for the navigation function. If the allocation is missing, a reviewer can challenge the level and pull the finished data back into 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.
Talk through the aircraft, records, evidence, deadline, and next useful step.