My hobbies and my work are starting to overlap.
I’ve been flying small planes all my life, and I’ve owned one for the past 17 years – a rare, mint condition, 1970 Aero Commander Lark. It’s a cute and sturdy little plane – carries four people for real (lots of “four place” airplanes really only have the weight carrying capacity to realistically schlep two or three people across the country), and trundles along at the relatively slow pace (in airplane terms) of 100 knots. This airplane does a wonderful job of getting from point A to point B faster than you can drive (usually). It is safe, simple, and easy and fun to fly.
As delivered from the factory it contained exactly zero microprocessors and no lines of software whatsoever. The only intelligence embedded in my Lark was mine and that of the aeronautical and mechanical engineers that designed the thing – an almost invisible slant to the right to offset the “P-factor” and other torque related effects that make it want to turn left under power, a bit of dihedral angle to the wing to make it tend toward stable, upright flight if you release the controls. A number of other elegant design decisions that built intelligence into the very fabric of the craft.
Unlike automobiles, airplanes have a very long service life. My 1970 Lark is more valuable and more viable as a personal aircraft today than it was new in 1970. I have upgraded it significantly from its original avionics (aircraft electronics) and have renewed the interior and paint, but it is otherwise just as designed in the late 1960s.
Enter aircraft number two.
Of course, as with almost any hobby, we eventually are compelled to upgrade. Aircraft number two joined the family just last week. It is a brand-new 2007 Cirrus SR-22 G3 Turbo. In terms of the impact of embedded systems on the world of light aircraft, no comparison could be more dramatic than that of these two planes. The Lark’s primary flight instruments are what is known as a “six pack” of “steam gauges”: six round mechanical instruments that operate either by vacuum-powered gyros or electrically-powered gyros, or “nothing”-powered instruments that work only from air pressure measured in and out of the airstream. The Cirrus has what’s known as a primary flight display (PFD), which is a single LCD monitor that contains all of the essential real-time flight information such as the aircraft’s attitude, airspeed, altitude, rate of climb, magnetic heading, and course bearing. Of course, all this information makes its way to the display courtesy of a complex, embedded computing system interconnected with most of the systems on the plane.
The Lark’s navigation system was a radio receiver called a “VOR” or VHF Omnidirectional Range. (Speaking of embedding, don’t you love acronyms that have other acronyms embedded in them? For example, VHDL = VHSIC Hardware Description Language, VHSIC = Very High Speed Integrated Circuit…). At the time, VOR was just about the most sophisticated navigation system available for small aircraft. VOR utilized ground-based radio transmitters that emitted composite signals that could be interpreted by the receiver in the aircraft to determine the magnetic bearing, or “radial,” from the station. With two VORs and a little trig (or a pencil and straight-edge on a chart), you could identify your exact location using only VOR signals and brainpower – all while simultaneously trying to operate the controls of an airplane, of course.
As you would certainly guess, the Cirrus navigates by GPS – two of them, in fact. As many of us know firsthand, GPS units are crammed with embedded computing complexity. We’ve already lost count of the embedded processors, and we’re only on the third paragraph. You see where we’re going here?
For a quaint bit of retro kitsch, the Cirrus also has fully functional VOR receivers. Thanks to the snail’s pace modernization of our air traffic system, they’re still useful for a variety of important tasks, including precision instrument landing approaches, audio broadcasts of weather and other flight information, and as a backup to the backup navigation alternative. Of course, GPSes in the Cirrus are not just stand-alone panel-mounted units as are the VORs in the Lark. They communicate over serial connections to a wide variety of other cockpit equipment, including the previously-discussed PFD, a secondary display called the multi-function display (MFD), the autopilot, and a set of communications radios integrated into the GPS units themselves. No longer do we have to look up radio frequencies on a chart or in a guide book. The radios can be pre-tuned with the relevant frequencies from a database as the GPS tracks our approach to a navigation waypoint.
The MFD is a complex embedded computing system in and of itself. It does what its name implies: displays a large variety of information to keep the pilot apprised of every possible aspect of the flight and of aircraft performance. It is capable of showing detailed mapping information, thanks to communication with the GPS units and a complete airspace and terrain database. It can superimpose XM satellite radio feeds with information about weather conditions, radar, and alerts and warnings posted by the governing authorities. It is connected to both on-board and ground-based lightning sensors that give us early alerts if dangerous thunderstorms are building along our path. It is connected to traffic sensors that follow the position of other aircraft by monitoring their transponder signals and will pop up an audio and visual alert to the pilot if another plane is on course to get in our way. It also warns us if we’re rapidly approaching any terrain that might cause a sudden deceleration.
The MFD also monitors just about everything about the engine, including exhaust gas temperatures, cylinder head temperatures, turbine inlet temperatures, oil pressure, manifold pressure, fuel flow, and fuel level. Of course, it warns us if anything goes wrong. It also has a database of every possible checklist for the airplane, including those for normal flight operations and several for abnormal operations and emergencies. The MFD is quite simply a gratuitous display of embedded computing capabilities in one unit that is coupled to almost every system in the airplane.
Did we mention an autopilot? In the Lark, my autopilot was engaged by a wedding ring. “Honey, would you take the controls while I look up these radio frequencies on the chart?” In the Cirrus, there’s a fully-functional autopilot that’s loaded up with still more embedded computing devices. It can communicate with both GPS units as well as the VOR receivers. It also gets data from the gyro platforms that feed the PFD and an altitude encoder. Given that information, the autopilot can perform an impressive number of functions, including automatically climbing (or descending) to a pre-determined altitude at a specified rate, holding a heading programmed into the PFD, tracking a GPS course from either GPS, and even flying both horizontal and vertical components of a precision instrument landing approach with data from the VOR receivers.
In fact, it is theoretically possible to complete an entire flight with the autopilot engaged, excluding the takeoff and first few hundred feet of climb, and the final few hundred of feet of descent on the landing. The pilot still has to push lots of buttons, turn a few knobs, and talk on the radio a lot, but the pilot’s stick and rudder skills become almost irrelevant.
The embedded systems in the Cirrus go on and on, and we’ve just touched the highlights. With all those millions of lines of code and all the MIPS of computing power we’re taking airborne, it’s amazing that we’ve got room left for passengers and cargo. It’s also amazing that the Lark could fly at all – completely devoid of embedded computing capability. Oddly, the part of the two planes that is most similar is the engine – digital engine control has not made it into mainstream light aircraft. Most still operate with magneto-based ignitions and arcane fuel systems that require no electrical system to operate. Aircraft engine designers are evidently suspicious of electronics.
Does all this technology make flying safer? The answer is inconclusive. In small planes, the single largest cause of accidents is pilot error. Unlike automobiles, your safety is not in the hands of others controlling vehicles that are constantly passing literally inches from yours. If your airplane hits something, it is most likely your fault. All of the embedded systems on these modern aircraft gather, analyze, consolidate, and present information to the pilot. It is still up to the pilot to make reasonable decisions based on all that data.
Certainly, the situational awareness provided by copious amounts of data about weather, traffic, terrain, engine performance, and other flight-safety related issues can assist a pilot in making safe decisions in their flight. At the same time, however, we’ve introduced an unprecedented level of complexity into the cockpit. With the Lark, I had a full and detailed understanding of the operation of every piece of equipment in the airplane. Given the proper tools and documentation, I could probably have repaired most of them myself. In the Cirrus, however, we have millions of lines of code in a networked multi-processor system loosely collaborating to perform complex tasks – in a system that was not designed top-down. Despite the protections of standards like DO-178B, that complexity is far too great for the pilot, or even the design engineers, to grasp completely.
As a case in point – the user’s group bulletin board that I monitor has an ongoing thread about an elusive bug in the autopilot system. Several pilots have reported that occasionally, when the system is in altitude capture mode, it will continue to fly the airplane at the specified rate of climb or descent right past the target altitude, not leveling off as it should. Obviously, such a bug would present a hazard to flight safety if the pilot recklessly depended on the system to level off in a descent without monitoring it as the autopilot dutifully descended into the ground.
Not so obviously, the conditions under which the bug might occur are not well understood. Perhaps it is a problem with the autopilot. Perhaps something in the PFD (where the target altitude and descent rates are set) is not being communicated correctly to the autopilot. Perhaps some combination of sensor malfunctions can cause the bug… The list of potential causes goes on and on. Pilots have posted scenarios where they believe that they’ve encountered the problem but none have demonstrated a way to reliably reproduce it. Meanwhile, pressure is mounting on the company – or all of the companies involved, to fix the problem.
Reminiscent of the infamous “unintended acceleration” issues in automobiles, there is also another plausible explanation. When engaging the altitude capture mode, the pilot’s finger might be holding the VS (vertical speed) key and missing the ALT (altitude hold) button entirely. This would put the aircraft in a constant rate of climb or descent with no target altitude – just as the pilot requested.
Of course, many on the discussion boards have proposed solutions to the problems. One even went so far as to say that the system was filled with “spaghetti code” that would certainly need to be re-written from scratch before any fix could be attempted. For those of us who have developed and maintained software for a decade or more, we recognize this as the battle cry of the recent software engineering graduate. They join the project, take a look at the software they’ve been asked to maintain or debug, and quickly announce that a complete rewrite is in order. We all know the end of this movie. If the rewrite is authorized, it takes about six times longer than fixing the bugs in the old system. Once complete, the new “clean” code has more bugs than the old, and all of the known problems have been replaced by new, elusive, mysterious ones. In software, age is an asset, not a liability. The best code is that which has been tested most thoroughly.
So, you see the problem here. I’ve taken my wonderful hobby and dropped it right smack-dab into my office. In the old days, I’d leave work and get into the airplane and my troubles would melt away as I climbed out over the lush Willamette Valley. Now, I’m reading newsgroups and speculating in articles about the solutions to an elusive embedded software bug – probably just one among thousands that are lurking in the bits between the myriad processors, memories, and communication links in my new airplane. It will be a sad day when I’m flying along and I see the message “new software updates are available for your plane – download now?”
Of course, it’s hard to complain over 219 knots true airspeed at flight level 250.
