Fly-by-wire - Wikiparency

# Fly-by-wire > [[PORTAL_Aviation|Aviation]] · [[PORTAL_Avionics|Avionics]] spine.  ## Microsims — three.js ### Fly-by-wire (three.js) <div class="microsim-player"> <iframe src="https://wikitube-3d-microsims.netlify.app/Fly-by-wire.html" width="100%" height="620" frameborder="0" loading="lazy" sandbox="allow-scripts allow-same-origin" title="Fly-by-wire — three.js microsim"></iframe> </div> **Open it full-screen:** [Fly-by-wire.html](https://wikitube-3d-microsims.netlify.app/Fly-by-wire.html) · library `threejs` · route `microsim/threejs/` ### Related microsims Live sims on neighbouring articles: - [[Aircraft_flight_dynamics]] - [[Flight_control_surfaces]] - [[Autopilot]] - [[Avionics]] - [[Head-up_display]] - [[Integrated_modular_avionics]] *Sim hosted off-article; the article owns the reference, not the runtime (WIKI_RULES §10.4).*  ## Overview In a conventional aeroplane the control column is connected to the elevator by cables, pushrods and bellcranks, and the geometry of that linkage fixes the relationship: so many inches of column, so many degrees of elevator, always the same, at every speed and every weight. The pilot learns the aeroplane by learning that mapping, and then learns to correct it — more column at low speed, less at high speed, a fistful of trim after every configuration change — because a fixed surface deflection does not produce a fixed response. A fly-by-wire aeroplane breaks that linkage. The stick is a transducer: it produces a number, the number goes to a computer, and what comes out is a command to an electrically signalled hydraulic actuator. Once the mechanical connection is gone the designer is free to decide what the stick *means*. On the Airbus A320 family and its descendants, and in different form on the Boeing 777 and 787, the answer is that the stick does not mean a surface deflection at all. In pitch it commands a **load factor**; in roll it commands a **roll rate**. The computer's job is to work out, continuously, whatever surface deflection produces the commanded motion at this airspeed, this weight and this attitude — and to refuse the parts of the demand that would take the aircraft outside its flight envelope. That refusal is the second half of the subject and the more contentious half. **Envelope protection** means that some pilot inputs are not obeyed. Pull fully aft on an A320 sidestick in normal law and the aircraft will give you 2.5 g, or the angle of attack limit, or a 30-degree nose-up attitude, whichever comes first, and it will not give you a stall. Roll fully to one side and it will stop at 67 degrees of bank. The demand is clipped; the surface stops short of what the pilot asked for. The microsim above renders both halves at once. The aeroplane is drawn with its ailerons, roll spoilers, elevators, trimmable stabiliser and rudder as separate moving surfaces, and the signal path is drawn as a loop physically encircling it: sidestick, three flight control computers, a voter, actuators, surfaces, the aircraft's own response, the sensors, and back to the computers. Amber packets are electrical commands, green ones are aerodynamics, cyan ones are measurement feedback. Hold the stick still and watch which quantity goes steady — the roll rate does, the aileron angle does not. Push past a protection and a translucent amber ghost appears alongside the real surface, showing the deflection the unclipped demand would have called for. Step the law down from normal to alternate to direct and the protections disappear one tier at a time, until in direct law the cyan packets stop entirely, because direct law has no feedback: it really is a wire. ## The physics ### The demand, not the deflection Start with the pitch axis. Sidestick deflection *s*y, normalised to the range -1 (full forward) to +1 (full aft), is converted to a commanded normal load factor: n_z_cmd = 1 + 1.5 * s_y for s_y >= 0 (full aft -> +2.5 g) n_z_cmd = 1 + 2.0 * s_y for s_y < 0 (full fwd -> -1.0 g) Those endpoints are not arbitrary: they are the limit manoeuvring load factors a large transport is designed and certified to. Title 14 CFR §25.337 sets the positive limit at *n* = 2.1 + 24000/(*W* + 10000), not less than 2.5 and not more than 3.8, and the negative limit at -1.0 for speeds up to *V*C; for an aircraft of airliner weight the formula lands on 2.5. The sidestick's full travel therefore spans exactly the structural envelope — the pilot cannot ask for a load the airframe is not certified to carry, because the ends of the stick's travel *are* the certified limits. With slats or flaps extended the same travel maps to +2.0 g and 0 g, matching the reduced limits for that configuration. Note what the neutral position means. Stick centred is not "zero elevator"; it is a command for 1 g. Releasing the stick means "hold the flight path", and that is why an A320 does not need re-trimming after a speed or configuration change — the demand has not changed, so the computer simply moves the surfaces to whatever new position keeps delivering it. Normal law adds automatic pitch compensation in a turn, commanding 1/cos φ up to the 33-degree bank threshold so a moderate turn does not cost altitude. Beyond 33 degrees the compensation stops and the pilot has to pull, which is why a steep turn still descends if you do nothing. ### C\*: what "load factor" means during the transient Load factor is the right cue for a large aeroplane at speed, but it is a poor cue at low speed, where a pilot judges a manoeuvre by pitch rate rather than by g. The classical resolution is the **C\* criterion**, introduced by Tobie, Elliott and Malcom in 1966, which blends the two into a single feedback variable: C* = n_z + (V_co / g) * q where *q* is the body pitch rate and *V*co is a **crossover velocity** of about 400 ft/s, roughly 122 m/s. Below the crossover the pitch-rate term dominates the blend; above it the load-factor term does. The microsim uses exactly this expression, with *V*co = 122 m/s shown live in the HUD. The command side has to carry the pitch rate that *belongs* to the commanded load factor, or the loop fights itself: a steady 2 g pull-up genuinely has a pitch rate, and a law that demanded *q* = 0 would never let the aircraft settle at the g. In any steady coordinated manoeuvre the angle of attack is constant, so the body pitch rate is q = (g / V) * (n_z - cos(gamma) * cos(phi)) one expression that covers a wings-level pull-up and a level turn alike. The sim forms C\*cmd from *n*z_cmd and that *q*, subtracts the measured C\*, and drives the difference to zero with a proportional-plus-integral loop on the elevator. (A common alternative is to high-pass filter — "wash out" — the pitch-rate feedback so it decays in a sustained manoeuvre; the effect is the same.) ### Auto-trim, and why the surface angle keeps changing The integral term is what makes the steady-state error zero, and it is also what makes the elevator angle uninteresting. Behind it sits a second, slower loop: **auto-trim**. The trimmable horizontal stabiliser (THS) — the whole tailplane, not just the elevator — is driven so as to return the elevator toward neutral. The stabiliser is the more powerful surface (in the sim, one degree of THS is worth about 1.9 degrees of elevator), so once it has taken the load the elevator sits near zero with full authority available in both directions. The visible consequence is the single most direct demonstration that the stick is not commanding a deflection. Park the stick aft and watch the HUD: the achieved load factor goes steady and *stays* steady, while the elevator reading shrinks toward zero and the THS reading grows. Same g, changing surface angle. The THS moves at a fraction of a degree per second — it is a screwjack, not a servo — so the process takes several seconds, and that slowness matters in the degradation story below. ### Roll: rate command, and the speed dependence that vanishes The lateral axis is simpler and shows the idea even more cleanly. Full lateral sidestick commands a roll rate of 15 degrees per second. The law measures the actual roll rate *p* and closes a loop on the error, driving ailerons and roll spoilers together. The rolling-moment equation is p_dot = (qbar * S * b / Ixx) * (C_l_da * delta_a + C_l_p * p * b / (2V)) so for a constant aileron deflection the steady roll rate is p_ss = 2 * V * C_l_da * delta_a / (b * |C_l_p|) which is proportional to airspeed. In the microsim's model, full aileron gives about 30 °/s at 220 kt and about 46 °/s at 340 kt. That is the mapping a conventional aeroplane hands its pilot, and it is why aileron feel changes so much across the speed range. In normal law it disappears. Command 7.5 °/s at 340 kt and the ailerons settle near 4 degrees; command the same 7.5 °/s at 220 kt and they settle near 6 degrees. The *rate* is identical; only the deflection differs, and the pilot never sees the deflection. Switch to direct law and the speed dependence comes straight back, because in direct law the stick position is multiplied by a fixed gain and sent to the surface. ### Clipping the demand: the four protections Envelope protection in the sim acts on the demand before the inner loop ever sees it. Four limits are computed each step and the most restrictive wins: **Load factor.** The demand is clipped to the +2.5 / -1.0 g structural range. This is a structural limit, not an aerodynamic one; it needs no air data and no cross-check, which is why it survives into alternate law when the others do not. **Angle of attack.** Above a threshold αprot the pitch law stops being a g demand and becomes an **alpha demand**: stick position now selects an angle of attack between αprot and αmax, and full aft stick gets αmax and no more. The sim implements this by converting the commanded alpha into the load factor it corresponds to at the current dynamic pressure and using that as a ceiling on *n*z_cmd. The limit is applied to a lead-compensated angle, α + *T*·(dα/d*t*), because a pure position limit always overshoots: by the time alpha reaches the limit the aircraft still has pitch rate to bleed off. And αmax sits *below* the aerodynamic stall angle — the protection is a fence in front of the cliff, not the cliff itself. Because the alpha limit is expressed in angle of attack and the structural limit in g, which one binds depends on airspeed: at high speed the aircraft reaches 2.5 g long before αprot, at low speed the reverse. Move the airspeed slider and watch the crossover; the HUD names whichever protection is doing the clipping. **Pitch attitude.** 30 degrees nose up, 15 degrees nose down, again with lead compensation on θ + *T*·*q*. Without the lead this limit is a positive-feedback trap: past about 9 degrees of climb angle, the cos γ term in the flight-path equation grows with attitude faster than the limit shrinks, and the aircraft hunts around 30 degrees instead of settling. **Bank angle.** A hard limit at 67 degrees, with the available roll rate budgeted against the *predicted* bank angle φ + *T*·*p*, so the limiter can command a rate back the other way before the angle is reached. Below 33 degrees, zero rate demand simply means "stay where you are", which is why a fly-by-wire airliner holds a 30-degree bank hands off while a conventional aeroplane slowly rolls further over under spiral divergence. Released beyond 33 degrees, the law rolls back to 33. ### The degradation ladder Protections are not free-standing. They are computed from measurements, by computers, and when either becomes untrustworthy the protections have to go. The A320 family formalises this as a ladder of **control laws**: **Normal law** — the full set: load factor, angle of attack, pitch attitude and bank angle protections, C\* pitch demand, roll rate demand, auto-trim. **Alternate law** — pitch remains a load-factor demand law and the structural load-factor limit is retained, but the angle-of-attack, pitch-attitude and bank-angle protections are lost. They are replaced by *stability* functions — low-speed and high-speed stability, which produce a nose-down or nose-up tendency and aural alerting rather than a hard barrier, and which the pilot can fly through. Roll reverts to direct. **Direct law** — stick position to surface deflection through a fixed gain. No demand, no feedback, no protections, no auto-trim. The stabiliser stays exactly where auto-trim last left it, which is why a reversion in the middle of a manoeuvre can hand the pilot an aircraft already trimmed well nose-up. In the microsim this is visible as the cyan feedback packets stopping: the loop is open. **Mechanical backup** — on an A320, the manual pitch-trim wheel and the rudder pedals, and nothing else. Enough to keep an aeroplane upright while the electrical system is restored; not enough to fly a normal approach. In the sim the law selector is a teaching device. On the real aircraft there is no such switch: reversion is automatic, driven by what has failed, and normal law is generally not recoverable in flight. ### Redundancy, and what a vote actually buys The sim models three flight control channels. Each computes the same law but with its own small dissimilarity, so the three answers agree closely and never exactly. The voter takes the **mid-value select** — sort the three, take the median. No matter how wrong a single channel is, the median is always one of the other two, so one arbitrary failure produces essentially zero movement of the aeroplane, and the voter never has to work out *which* channel is broken. Fail a channel in the sim and watch what happens in order. The failed computer keeps talking: it stays on the bus emitting a hardover for about half a second while its own internal command/monitor comparison catches up. During that window the only thing protecting the aircraft is the vote, and the load factor trace barely twitches. Then the computer declares itself failed and drops out. Two healthy channels remain, still cross-comparable, and normal law is retained. That is the payoff of redundancy: the first failure costs nothing at all. Fail a second and the picture changes. One channel has nobody left to check it against; a pair can *detect* a disagreement but cannot say which member is wrong, and a single survivor cannot even do that. An unmonitored computer is not trusted with envelope protection, so the law reverts to alternate. Fail the third and only the mechanical backup remains. Real architectures are deeper and less symmetric. The A320 has two ELACs, three SECs and two FACs, built by different suppliers, running dissimilar software, each internally split into a command lane and a monitor lane that must agree. The Boeing 777 uses three primary flight computers, each containing three dissimilar lanes built around three different microprocessor families compiled from a common Ada source by different compilers, with voting at several levels. The reason for all this **dissimilarity** is that redundancy only protects against *independent* failures: three identical computers running identical software share every software fault they contain, and a vote among them returns the same wrong answer three times. ### Two philosophies, and the limits of both Airbus and Boeing made genuinely different choices about how much authority the computer holds, and the difference is real rather than marketing. On Airbus aircraft in normal law the protections are **hard**. The pilot cannot command beyond αmax, beyond 67 degrees of bank, or outside the load-factor envelope, no matter how hard the sidestick is pushed. The sidesticks are not mechanically linked to each other and are not back-driven by the autopilot; stick force is a spring, not a measure of aerodynamic load. On Boeing fly-by-wire aircraft the protections are **soft**. The 777 and 787 also fly a computed command law — the pitch law is C\*U, adding a speed-stability term so the aeroplane retains a conventional apparent trim speed — and they include bank angle, stall and overspeed protections. But those protections are implemented as increasing control force and as commands the pilot can pull or push through. The columns and wheels are mechanically interconnected between the two pilots and are back-driven by the autopilot, preserving a conventional tactile picture. The arguments cut both ways and neither is obviously right. A hard limit cannot be defeated by a startled or overloaded crew, and it lets the designer certify a manoeuvre margin that does not depend on human performance. A soft limit preserves the pilot as the final authority for the case the designers did not foresee, in which exceeding a limit might be the correct action, and it keeps the aerodynamic situation legible through the controls. Both architectures are certified to the same airworthiness standard and both have accumulated excellent service records over decades. What is not in dispute is that the choice is a *design* choice about where authority sits, not a difference in whether the aircraft is computer-controlled: both are. ### Protection is not a guarantee The most important limitation of envelope protection is structural, not philosophical: **a protection is only as good as the measurement it is built on**. Angle-of-attack protection is computed from angle-of-attack vanes and from calibrated airspeed. If the air data reference is not trustworthy, the protection cannot be trustworthy either, and a system that continued to enforce a limit computed from bad data would be more dangerous than one that stopped. The microsim exposes this directly. Switch the air data reference to invalid and the HUD stops reporting a sensed angle of attack — the aircraft still *has* one, and the sim still shows the true value on a separate line, but the computer no longer knows it. Alpha protection disappears and the law reverts to alternate, even though all three computers are perfectly healthy. The same stick input that was clipped a moment ago now goes through unmodified. This is the mechanism at the technical heart of the loss of Air France flight 447 on 1 June 2009, an Airbus A330-203 registered F-GZCP. According to the final report of the French Bureau d'Enquêtes et d'Analyses, obstruction of the pitot probes by ice crystals at cruise altitude produced inconsistent airspeed indications; the autopilot and autothrust disconnected and the flight control system reverted to alternate law, in which angle-of-attack protection is not available. The aircraft was subsequently held in a nose-up attitude, entered an aerodynamic stall and remained in it until impact. The report also records a related sensor-validity effect: the stall warning ceased when the measured airspeed fell below 60 kt, because angle-of-attack values are treated as invalid below that speed, and resumed when the readings became valid again. Among the consequences were changes to pitot probe standards and to the presentation of unreliable-airspeed information. The narrow lesson here is not about crew performance, which the report addresses at length and which is outside the scope of a systems note. It is that the degradation ladder and the air data validity logic are where the guarantee ends. Any claim of the form "this aircraft cannot be stalled" is really a claim of the form "this aircraft cannot be stalled while the flight control system is in normal law and the air data it depends on is valid". ## Controls -> what each maps to | Control | Symbol | Range / units | What it does physically | |---|---|---|---| | Sidestick pitch (drag pad, Up/Down arrows) | *s*y | -1 to +1, dimensionless | Commands load factor: *n*z_cmd = 1 + 1.5 *s*y aft, 1 + 2.0 *s*y forward, so full travel spans +2.5 g to -1.0 g. Spring-centred: released, it commands 1 g. | | Sidestick roll (drag pad, Left/Right arrows) | *s*x | -1 to +1, dimensionless | Commands roll rate: *p*cmd = 15 *s*x °/s in normal law. In direct law the same input becomes δa = 25 *s*x degrees of aileron. | | Park the stick (H) | — | on / off | Defeats the centring spring so a demand can be held indefinitely. A simulator convenience; a real sidestick is always sprung. | | Hold full aft / Hold full right | — | — | One-click demonstrations: parks the stick at full travel in one axis. | | Control law selector (1 / 2 / 3) | — | NORMAL / ALTERNATE / DIRECT | Selects a *ceiling*, never a floor. You may always ask for a lower law; the system cannot give you a higher one than its state supports. | | Envelope protections (P) | — | on / off | Comparison toggle: removes the clipping while leaving normal law's demand structure intact. Not a flight-deck control; it exists to make the with/without difference visible. | | FCC 1 / FCC 2 / FCC 3 (Q / W / E) | — | healthy / failed | Makes that channel emit a hardover. It stays in the vote for 0.55 s before its own command/monitor comparison takes it offline. 3 or 2 engaged -> normal law; 1 -> alternate; 0 -> mechanical backup. | | Air data reference valid (A) | — | valid / invalid | Invalidates measured α and calibrated airspeed. Removes angle-of-attack protection and forces at least alternate law, with all computers healthy. | | True airspeed | *V* | 175 to 340 kt (90 to 175 m/s) | Sets dynamic pressure *q̄* = ½ρ*V*². Changes surface effectiveness, the roll rate available per degree of aileron, and which protection binds first. Held constant by the model. | | Reset (R) | — | — | Normal law, three healthy channels, valid air data, 200 kt, trimmed at 1 g. | | Orbit / zoom | — | — | Camera only. Orbit under the ring to see the feedback path pass beneath the airframe. | ## Learning objective **Understand that a fly-by-wire stick commands a motion rather than a surface position, and that the envelope protections which follow from that are conditional on the control law in force and on the validity of the air data underneath it.** Three things to try, in order. First, park the stick fully right and watch the roll rate settle at exactly 15 °/s while the aileron angle settles wherever this airspeed happens to require; then move the airspeed slider and watch the aileron angle change while the rate does not. Second, park the stick fully aft at 200 kt and watch the demand get clipped — the amber ghost surface shows the deflection you asked for, the solid surface shows what you got, and the HUD names the binding protection. Third, do the same thing three more times: with protections switched off, in alternate law, and with the air data reference invalidated. The same input produces a controlled manoeuvre in the first case and an aerodynamic stall in the other three, and in the last of them every computer on board is working perfectly. ## Limits and connections The model is deliberately reduced, and the ways in which it is reduced are worth stating plainly. The airframe is A320-class and the published reference geometry is real — wing area 122.6 m², span 34.10 m, mean aerodynamic chord 4.19 m, overall length 37.57 m — but the moments of inertia and every aerodynamic derivative are representative transport-aircraft values, not manufacturer data. They are chosen to put the short-period frequency, the roll mode time constant and the control powers in the right range; they are not a model of any particular aeroplane. The post-stall lift curve is likewise a crude linear break past CLmax, present only so that turning the protections off has a visible consequence; real post-stall behaviour is unsteady and hysteretic. Sideslip is zero throughout. The turn is assumed perfectly coordinated, with the yaw rate set from the coordinated-turn relation rather than integrated from a yaw moment equation, so there is no Dutch roll, no adverse yaw and no yaw damper dynamics — the rudder deflection shown is illustrative. [[Aircraft_flight_dynamics]] carries the full six-degree-of-freedom picture that this one truncates. True airspeed is held constant by the slider. There is no thrust or drag model, so a stall here does not decay in speed the way a real one does, and the low-speed and high-speed *stability* functions of alternate law — which act on speed rather than on angle of attack — are described above but not simulated. For the same reason A.FLOOR is an annunciation only: on the real aircraft it commands take-off/go-around thrust, and there are no engines in this model. The protection thresholds are representative of the Airbus normal-law family in the clean configuration. Real values are weight-, configuration- and Mach-dependent, are computed continuously rather than fixed, and are not published as constants; the 67-degree bank limit, for instance, reduces to 45 degrees when high-angle-of-attack or high-speed protection is active. Treat the numbers here as illustrative of the structure, not as data. Similarly, the three channels are one law evaluated with three small dissimilarity gains and offsets, not three independently written programs: the target is the vote and the monitoring hierarchy, not numerical divergence between implementations. The real thing also rests on software assurance processes — DO-178C design assurance levels, formal methods, independent verification — that no simulation can show. [[Integrated_modular_avionics]] covers the platform side of the same problem: how these functions came to share hardware without sharing failure modes. Outward, [[Flight_control_surfaces]] is the mechanical layer this article sits on top of. [[Autopilot]] is the layer above: an autopilot on a fly-by-wire aircraft does not drive surfaces, it issues the same demands the sidestick issues, which is why autopilot disconnect leaves the pilot holding an aeroplane that still flies the same way. [[Head-up_display]] is where the flight path vector and the alpha-protection strip that make these limits legible to the crew are actually drawn, and [[Avionics]] is the wider system in which all of this is one line-replaceable set among many. ## References - Tobie, H. N., Elliott, E. M., and Malcom, L. G. "A New Longitudinal Handling Qualities Criterion." *Proceedings of the 18th Annual National Aerospace Electronics Conference (NAECON)*, Dayton, Ohio, 1966, pp. 93–99. (Origin of the C\* criterion and the crossover velocity.) - Gibson, J. C. *Development of a Methodology for Excellence in Handling Qualities Design for Fly by Wire Aircraft*. Delft University Press, Series 03: Control and Simulation 06, 1999. ISBN 90-407-1842-3. - Brière, D., and Traverse, P. "AIRBUS A320/A330/A340 Electrical Flight Controls: A Family of Fault-Tolerant Systems." *Digest of Papers, FTCS-23: The 23rd International Symposium on Fault-Tolerant Computing*, IEEE Computer Society Press, 1993, pp. 616–623. - Traverse, P., Lacaze, I., and Souyris, J. "Airbus Fly-By-Wire: A Total Approach to Dependability." In *Building the Information Society* (IFIP 18th World Computer Congress), edited by R. Jacquart, Kluwer Academic Publishers, 2004, pp. 191–212. - Favre, C. "Fly-by-wire for commercial aircraft: the Airbus experience." *International Journal of Control*, Vol. 59, No. 1, 1994, pp. 139–157. - Yeh, Y. C. "Triple-Triple Redundant 777 Primary Flight Computer." *Proceedings of the 1996 IEEE Aerospace Applications Conference*, Vol. 1, 1996, pp. 293–307. - Yeh, Y. C. "Design Considerations in Boeing 777 Fly-By-Wire Computers." *Proceedings of the Third IEEE International High-Assurance Systems Engineering Symposium (HASE '98)*, 1998, pp. 64–72. - Tomayko, J. E. *Computers Take Flight: A History of NASA's Pioneering Digital Fly-By-Wire Project*. NASA SP-2000-4224, National Aeronautics and Space Administration, 2000. (The F-8 Crusader DFBW testbed, first flown 25 May 1972.) - Bureau d'Enquêtes et d'Analyses pour la sécurité de l'aviation civile (BEA). *Final Report on the accident on 1st June 2009 to the Airbus A330-203 registered F-GZCP operated by Air France flight AF 447 Rio de Janeiro – Paris*. BEA, July 2012. - Federal Aviation Administration Human Factors Team. *Report on: The Interfaces Between Flightcrews and Modern Flight Deck Systems*. FAA, 18 June 1996. (Contemporary assessment of automation authority and mode awareness across manufacturers.) - Title 14, Code of Federal Regulations, Part 25 — *Airworthiness Standards: Transport Category Airplanes*, §25.335 (design airspeeds), §25.337 (limit manoeuvring load factors) and §25.1309 (equipment, systems and installations). - RTCA, Inc. *DO-178C: Software Considerations in Airborne Systems and Equipment Certification*. RTCA, 2011. - Pratt, R. W., editor. *Flight Control Systems: Practical Issues in Design and Implementation*. IEE Control Engineering Series 57, Institution of Electrical Engineers, 2000. ISBN 978-0-85296-766-9. - Stevens, B. L., Lewis, F. L., and Johnson, E. N. *Aircraft Control and Simulation: Dynamics, Controls Design, and Autonomous Systems*. 3rd edition, Wiley, 2016. ISBN 978-1-118-87098-3. - Cook, M. V. *Flight Dynamics Principles: A Linear Systems Approach to Aircraft Stability and Control*. 3rd edition, Butterworth-Heinemann, 2013. ISBN 978-0-08-098242-7. - Airbus S.A.S. *A320 Aircraft Characteristics — Airport and Maintenance Planning*. Airbus Customer Services, Blagnac. (Source of the published airframe geometry used for the drawn model.) **On the spine:** [[Avionics]] · [[Fly-by-wire]] · [[Autopilot]] · [[Head-up_display]] · [[Traffic_alert_and_collision_avoidance_system]] · [[Terrain_awareness_warning_system]] · [[Radio_navigation]] · [[Radiation_hardening]] · [[Radar]] · [[Air_traffic_control]] · [[Aviation]].  *Connected to the Apex Spine:* Fly-by-wire → [[Vortex_generator|Vortex generator]] → [[Fluid_dynamics|Fluid dynamics]] — [[WT!Thury_Hydrodynamics_Compendium|Compendium]] section 1, *Fluid dynamics*.   **Part of the [[Aviation]] hub** — main article for section A30, *Fly-by-wire*. Related sections: Wing warping · Flight envelope · [[Autopilot]]. **Part of the [[Avionics]] hub** — main article for section X14, *Aircraft flight-control system*. Related sections: [[Autopilot]] · FADEC · Flight envelope.  ## Wikipedia : Wikitube **Strict pair:** [Wikipedia](https://en.wikipedia.org/wiki/Fly-by-wire) : [Wikitube](https://en.wikitube.io/wiki/Fly-by-wire) --- *PORTAL_Avionics three.js batch · 2026-08-05 · sim staged in `_3d_deploy_stage/`.*