Autopilot TSO
Autopilot system evidence support for TSO authorization
Autopilot system TSO evidence readiness gets the certification data for an automatic flight control system into shape for a TSO authorization, where the center of gravity is system safety rather than a single performance number. A certification engineer runs it for the supplier once the architecture is set but the safety, software, and verification evidence still sit in separate stacks. The work checks the ARP4761A safety assessment, confirms the software DAL follows from the failure conditions, and walks the requirements trace from system through software to verification. You get an evidence gap list organized around the safety argument, a trace map from failure condition to verified requirement, and a closure sequence that protects the assurance-level chain.
When this review is needed
- An autopilot is heading for a TSO authorization and the safety, software, and verification evidence has never been checked as one chain.
- The software DAL was assigned early and no one has confirmed it still follows from the current failure condition set.
- System requirements, software requirements, and verification cases were produced by separate teams and their trace is unproven.
- A prior review questioned the safety assessment and the supplier wants the weak links found before submission.
The problem
An autopilot lives or dies on its safety argument, and that argument threads through an ARP4761A assessment, a set of failure conditions, an assigned development assurance level, and a software life-cycle that has to match it. In practice the safety work, the requirements, and the verification evidence are authored by different teams at different times, and the chain that should run cleanly from a failure condition down to a verified requirement is exactly where it frays. The engineer preparing the package inherits pieces that each look rigorous but do not connect.
What gets reviewed
- The ARP4761A safety assessment checked for consistency with the architecture and failure conditions
- Software and hardware development assurance levels traced to the failure conditions that drive them
- System-to-software requirements allocation verified as complete and consistent
- Verification evidence matched to requirements at the assigned assurance level
- The ARP4754B development process evidence checked for the objectives the level requires
- Derived requirements and their safety review confirmed present
Scope this review
Tell us the asset, the event, and the evidence in scope, and we will outline a focused first engagement.
Identify what is missing against the means of compliance.
What gets validated
- Each software DAL follows from a documented failure condition, not an early assumption
- Every system requirement allocates to software or hardware requirements with none orphaned
- Each requirement carries verification at the rigor the assigned level demands
- Every derived requirement is fed back into the safety assessment as the process requires
- The failure conditions in the safety assessment reconcile with the current architecture
Evidence normally required
- The ARP4761A safety assessment and its failure condition classification
- The ARP4754B development process data and assurance-level assignments
- System, software, and hardware requirements with their allocation
- The DO-178C software life-cycle data at the assigned level
- Verification cases, procedures, and results
Common discrepancies
- A software DAL assigned early that no longer matches the current failure condition classification
- System requirements with no allocation down to software or hardware
- Verification evidence thinner than the assigned assurance level requires
- A derived requirement never returned to the safety assessment for review
What is at stake
A break in the assurance chain is the most expensive kind of gap to find late, because raising a software DAL after the fact can invalidate verification already done and reopen the life-cycle. An authority that doubts the safety assessment will hold the whole authorization, and a mis-assigned DAL discovered downstream can force rework that ripples through every requirement it touches.
How the work runs
Read the safety argument
Take the ARP4761A assessment and its failure conditions as the spine the rest of the evidence must hang from.
Confirm the assurance levels
Trace each software and hardware DAL back to the failure condition that drives it and flag any mismatch.
Walk the requirements trace
Follow allocation from system to software to verification and mark every orphan or thin link.
Sequence to protect the chain
Order closure so assurance-level and trace breaks resolve before dependent verification is relied on.
What the buyer receives
- An evidence gap list organized around the system safety argument
- A trace map from failure condition through requirement to verification
- A closure sequence that protects the development assurance-level chain
Who uses the output
- Certification engineers assembling the autopilot TSO data package
- Safety and software leads confirming the assurance chain is intact
- Program managers judging which chain breaks must close before submission
How the work fits into the transaction or program
This readiness pass is the hinge between an autopilot's development evidence and its TSO submission. It verifies the one thing an authority scrutinizes hardest, the safety-to-software-to-verification chain, and the trace map it produces carries forward into any installation approval that has to show the same chain holds in context.
Start with a single asset
Confirm requirements map to substantiating evidence.
Jurisdiction-specific considerations
FAA and EASA both accept ARP4754B and ARP4761A as means of compliance for a system like an autopilot, but they differ in emphasis on how the safety assessment and assurance-level rationale are documented. The gap list marks where a safety argument framed for one authority will need reframing for the other.
Regulatory limits
The work checks and organizes the supplier's evidence against the process objectives. It does not perform the safety assessment, assign the assurance level on the authority's behalf, approve the software, or grant the TSO authorization. Those judgments stay with the applicant and the authority.
What this review does not cover
- Authoring the ARP4761A safety assessment or the requirements
- Executing software verification or raising the assurance level
- Submitting the package or negotiating the authorization
Specific to this review
- The most damaging autopilot gap is a software DAL that no longer follows from the current failure conditions, because correcting it can invalidate verification already completed.
- Derived requirements are a recurring blind spot: they are generated during design but never fed back into the safety assessment, which the process requires.
- An autopilot package can have complete-looking safety, requirements, and verification evidence and still fail, because the failure is in the links between them, not the pieces.
Sources
U.S. Government (eCFR). Type certificates, STCs (Subpart E), TSO authorizations (Subpart O), PMA (Subpart K), and export airworthiness approvals (Subpart L).
European Union / EASA. EASA design and production certification, STCs, ETSO authorizations, and EASA Form 1 release.
RTCA. Environmental qualification test categories and procedures referenced by TSO and equipment qualification.
RTCA. Objectives and lifecycle data for airborne software assurance, by design assurance level (DAL A-E).
Frequently asked questions
What happens if the software DAL turns out to be wrong?
If the assigned level is lower than the failure conditions justify, the software life-cycle evidence may not meet the required objectives, and verification done at the lower rigor may not count. The review surfaces that early so the level can be corrected before more verification is built on it.
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.