Envelope Protection
"Envelope Protection" is the name we give to two autopilot features that work to prevent stall and overspeed. In this post I'll discuss only the stall prevention part.
Considering how an autopilot works can easily become an exercise in flight dynamics. Fortunately it's a familiar topic for pilots! We'll introduce some of the mathematics along the way, and I think that whether you like math or not, you'll be able to connect your piloting knowledge to the equations.
Flying can be thought of as a hierarchy of decision making. Naturally you want to keep the airplane right side up, a very tactical consideration. You also want to avoid weather and traffic, achieve and capture an altitude, prevent stall, and, eventually, get there! And you more or less want all those things at the same time. A human's actually a pretty impressive computing machine, and the prioritization humans do almost unconsciously can be tricky to program.
Following the human model just described, the autopilot treats envelope protection as one of several simultaneous objectives. Like you, it wants to control pitch, limit g's, achieve commanded rate of climb & etc all at the same time. We employ two general techniques to get this done in the DFC series autopilots, one of them a little bit unusual...
First, and conventionally, many commands can be met while while constraints are simultaneously applied elsewhere. For example, upon encountering the glideslope, the AP will try to pitch over and capture it subject to the constraint that the g factor not drop too low. This is pretty easy thing to implement; somewhere in the autopilot there's a signal that represents the g load on the airplane. That value gets first calculated as a command by the glide slope control loop and then passed on to other functions for checking. One of those functions is the g limiter: whatever the REST of the autopilot would like to do, g's are constrained to the range of 0.2g to 3g. Once g command is determined, the next function down the line figures out how to achieve those g's using elevator servo commands.
I have used this as the first example because you do the same thing when you are flying. Your arm is the servo in a feedback control loop, pulling harder when you want more load factor from the airplane. The feedback comes from your body, which can measure g a couple of ways.
So, the constraints are relatively easy to understand as limitations applied to whatever else you want to do. Multiple competing objectives are a little more difficult to implement in software, but they're still easy enough to understand. For instance, given a vertical speed command, an altitude target, and "don't stall" as simultaneous mandates, whatyou do is prioritize them. "Don't stall" is most important, then vertical speed, and finally the altitude command is the last priority. What the DFC90/100 does, (and perhaps what you do too, if you think about it) is run these control loops at the same time, one for altitude hold and one for vertical speed. This is the second, and more unusual technique I mentioned above.
For contrast let's briefly consider the conventional approach. The AP could use various mode transition criteria to switch between loops, and only run one control loop at a time. That's common practice, however you can often feel a mode switch happening in those other autopilots, or notice that the switch didn't happen at the right time. Avidyne does not do it that way for critical pitch loops.
These loops are like two distinct imaginary pilots, competing for stick time. Perhaps the altitude autopilot is trying to point steeply up because the altitude command is 5000 feet above the present altitude, way up there! Meanwhile the other one, the VS control loop, is perfectly happy holding 800 feet/sec and wants to keep pitch right where it is at 7 deg. The prioritization logic chooses VS over altitude and now it's clear why: it would be crazy to use the altitude loop while we're still 5000' away from the command. The very reason there's a climb loop is that the altitude hold algorithm is so particular that, in responding proportionately to the very large altitude discrepancy pertaining during a climb, it would always be calling for an unsustainable aircraft maneuver: "Oh my gosh we're 5 THOUSAND feet off altitude, point the nose straight up!" Instead the climb loop overrides the altitude loop until the aircraft reaches a height where it can respond linearly to command inputs based on altitude error.
What then controls the Avidyne autopilot's hand-over logic, and how is it different? Well, since we're running all the loops all the time, we can compare them. The capture transition happens at precisely that moment when the two control algorithms agree on the pitch command. That way it's perfectly smooth handover every time. This is a helpful way of thinking about the different modes too; that they are all "in there" somewhere, active all the time, computing and offering their elevator servo command to a supervisory function which selects from between the competing inputs. Now imagine that one of these behind-the-scenes autopilot controllers is concerned only with lift. It's not thinking about thevertical speed, or the altitude or the pitch angle or anything else: just lift. With that foundation, we are now in a good position to understand envelope protection.
Stall prevention is just one more control loop that's running all the time. It works in the background, and generally has high tolerance for whatever else the AP wants to do. However, the stall prevention algorithm has the absolute last word and it may take over the "pitch rate control loop" at any time: it's never switched off. Now, pitch rate is the innermost heart of the autopilot, analogous in humans perhaps to the subliminal "thinking" that keeps you balanced while walking, or when you’re flying an airplane, manages the g loading.
The metaphor isn't far fetched either, because there is an exact relationship between the autopilot's control of pitch rate and your control of g loading. It's called speed. The equation a = w x Vtas is unavoidable here. The variable w represents pitch rate1 and a is the kinematic acceleration meaning the motion that results from the g forces applied to the aircraft. So we see that g's are proportional to pitch rate, and their ratio is speed. This is the centripetal acceleration equation from high school physics. Of course, there is one more component of the g's you feel, and that is the one g of gravity. We all understand the underlying concept perfectly well: it takes lift to fight gravity and it takes still more lift to turn the airplane, and you feel both of those in the seat of your pants as g loading.
At this point we have outlined almost all the computations that have to happen. The last one is a possibly familiar lift equation: Lift = 1/2 Sref * rhoSL * Vias2 * CL.2 In words, the wing can generate lift in proportion to indicated airspeed and lift coefficient (CL) which you control through the angle of attack. We know we can not a exceed well defined maximum lift coefficient, called (no surprise) CLmax. Try to use more angle of attack and the stall buzzer goes off as you approach flow separation. So maximum lift is known. Further, lift and g are related by mass and we know earth's g is 32.2'/sec2 so subtracting those (Liftmax - m*g) tells you how much extra lift is left over. That surplus lift can be used for acceleration, to turn the plane and that's pitch rate. It's important to mention the difference between kinematic and measured acceleration. Because of gravity you measure one g of acceleration even when you aren't kinematically moving at all. So what you (and the accelerometers inside the AHRS) feel is the vector difference between kinematic acceleration and g: ameas = akine - g3. Since this is a vector equation, a lot of trigonometry arises as soon as we depart from zero pitch and roll, but for now if you will just stipulate that the geometry is properly accounted for, we can imagine that a fixed Lift budget gets“spent” on counteracting gravity and generating pitch rate. If there's not enough lift because we're going too slow, then we either can't turn or can't fight gravity or both, you pick. The autopilot does this math and reduces things accordingly, starting with bank (limiting turns) and then grudgingly constraining pitch rate too. It is by controllling pitch rate that we limit g, hence lift.
What's interesting here is all the things we didn't have to consider here. There is no mention of vertical speed, or altitude, or airspeed control, or even pitch. Those are all important but do not matter to the equations implementing stall prevention. The algorithmthat's running behind the scenes is: "calculate the lift, subtract gravity, see what's left to accelerate the aircraft and then don't allow the pitch loop to try any harder than that." That might mean the calculated pitch rate comes out negative: you can fly slower than stall speed if you're willing to pitch over while doing it! Finally, to be conservative, envelope protection always assumes max weight, just like the colored arcs on your airspeed indicator.
That completes the discussion of this envelope protection. The key points are that it’s always there in the background, calculating lift and keeping the airplane from approaching stall. You should never hear the stall buzzer while your DFC autopilot or flight director is engaged. (Well, providing you’re following the flight director.)
notes
1 w is the greek symbol for angular rate of rotation, a vector including not just pitch but roll and yaw rate as well.
2 Here I must use the programmer's * to denote multiplication because later I will need "x" for the vector cross product.
3 The bold font means these are vectors, and kinematic is construed to mean "in consequence of motion.