Autopilot STC
Autopilot system evidence support for STC installation approval
Autopilot STC installation evidence support prepares the data showing an automatic flight control system is safe and functional once it is coupled to a specific aircraft's flight controls, sensors, and displays under a supplemental type certificate. A certification engineer runs it for the modifier while the installation architecture settles, before the STC package is built. The emphasis moves from the equipment's internal safety case to aircraft-level integration: servo authority and disconnect, sensor sourcing, interface behavior, and the failure effects the coupled system creates. You receive an installation evidence gap list, a trace map from the aircraft-level basis to the installed configuration, and a closure order that clears the integration safety effects first.
When this review is needed
- An autopilot with an equipment authorization is being coupled to a new airframe's flight controls and the installation safety case has to be built.
- Servo authority, disconnect behavior, or override forces differ from what the equipment safety assessment assumed.
- The autopilot draws attitude, air data, or heading from aircraft sources that were not part of the equipment case.
- The STC applicant needs the aircraft-level failure effects documented before the package is compiled.
The problem
An autopilot's equipment safety case assumes an operating context; the STC has to prove that context is real on this aircraft. Servo authority against these control surfaces, disconnect and override forces this crew will feel, sensor sourcing from these systems, and the failure effects the coupled installation produces are all installation-level questions the equipment evidence never answered. The engineer building the STC package has to construct an aircraft-level safety argument from installation data that was not authored with that argument in mind.
What gets reviewed
- Servo authority, rate, and disconnect behavior against the installed flight controls
- Attitude, air data, and heading sourcing in the installed sensor configuration
- Interface behavior between the autopilot and the aircraft systems it couples to
- Aircraft-level failure effects of the coupled installation, including runaway and hardover
- The installed configuration reconciled to the equipment authorization it relies on
- Departures from the equipment safety assumptions introduced by the installation
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
- Servo authority and disconnect behavior on the installed controls stay within the assumptions the equipment case relied on
- Every sensor source feeding the autopilot is documented and its failure modes assessed at aircraft level
- Interface behavior with each coupled aircraft system is verified, not assumed
- Runaway, hardover, and disconnect failure effects are analyzed for this installation
- Any departure from the equipment safety assumptions carries installation-level substantiation
Evidence normally required
- The equipment authorization and the operating assumptions its safety case declared
- Installation drawings covering servo, actuation, and disconnect provisions
- Interface control information and sensor sourcing for the installed configuration
- The aircraft-level functional hazard information relevant to the coupled system
- Crew procedures for engagement, disconnect, and override
Common discrepancies
- Servo authority or disconnect forces on this aircraft outside what the equipment case assumed
- A sensor source feeding the autopilot whose failure modes were never assessed at aircraft level
- Coupled-system interface behavior verified by assumption rather than by evidence
- A runaway or hardover failure effect analyzed for the equipment but not for the installation
What is at stake
Installation-level failure effects that are not documented and bounded are where an autopilot STC draws its hardest authority scrutiny, because a runaway or hardover on this aircraft is a flight-safety event. An unresolved servo authority or disconnect question stalls the approval, and a late discovery about sensor sourcing can force an architecture change when the design is nearly frozen.
How the work runs
Carry over the equipment case
Read out the operating and safety assumptions the equipment authorization declared so the installation is measured against them.
Assess the coupled installation
Evaluate servo authority, disconnect, sensor sourcing, and interfaces as coupled to this aircraft.
Analyze aircraft-level failures
Work the runaway, hardover, and disconnect effects for the installed configuration.
What the buyer receives
- An installation evidence gap list scoped to this airframe and its flight controls
- A trace map from the aircraft-level basis to the installed configuration
- A closure order that resolves the integration safety effects ahead of submission
Who uses the output
How the work fits into the transaction or program
This work extends the autopilot's equipment safety case onto a specific aircraft and its flight controls. It depends on the equipment evidence being sound and feeds the STC package, so it commonly follows the equipment readiness pass rather than replacing it, carrying the same safety chain into the installation context.
Start with a single asset
Confirm requirements map to substantiating evidence.
Jurisdiction-specific considerations
FAA and EASA both route an autopilot installation through an STC but differ in how aircraft-level failure effects and crew interface are expected to be substantiated. The gap list flags where installation evidence prepared for one authority will need extension before it supports approval under the other.
Regulatory limits
The work assembles and checks installation evidence against the aircraft-level basis. It does not grant the STC, approve the installation, perform flight test, or determine that the modified aircraft is airworthy. Those decisions remain with the authority and the STC holder.
What this review does not cover
- Performing the installation, ground checks, or flight test
- Authoring the aircraft-level functional hazard assessment
- Filing the STC or securing its approval
Specific to this review
- An autopilot STC turns on installation-level failure effects like runaway and hardover, which the equipment safety case does not resolve because they depend on the aircraft's controls.
- Servo authority and disconnect forces that were fine on the equipment's assumed platform can exceed the safe envelope on a different airframe, so they are checked against the installed controls.
- Sensor sourcing is a frequent late surprise, because the autopilot draws attitude and air data from aircraft systems whose failure modes were outside the equipment case.
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
Isn't the autopilot's safety case already done at the equipment level?
The equipment safety case is done against assumed operating conditions. The STC has to show those conditions hold once the autopilot is coupled to your aircraft's controls and sensors, and it has to analyze the failure effects that coupling creates. That aircraft-level work is what this pass prepares.
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.