How to start up a Boeing 737 [video]
loopinsight.com
loopinsight.com
Just as web-UI design can be an all-consuming obsession to get it 'just-so', you can loose yourself in comparisons between rotary switches - finding one with just the right torque and a satisfying positive click, locking toggle switches, the colour of the panels and the colour of the filled engravings to get the readability good in both direct sunlight and dim red-lit cabins, the pride you take in wiring looms that no other humans will likely ever see. It's of course not all fun and games, people's lives will depend on the quality of that wiring loom, and the spark from an unsealed toggle switch in the oxygen-rich cabin is what caused the Apollo 1 fire ( http://en.wikipedia.org/wiki/Apollo_1 ).
So videos like this are quite a source of design inspiration!
Relatedly: if you wonder what goes into making nice panels and wiring looms, have a flick through this: http://www.rbracing-rsr.com/wiring_ecu.html it's motorsport but it's basically the same story for aircraft.
0:02 ground power turned on. The plane is basically "plugged in" to an outlet. This
turns on the electric systems from that power source.
0:03 cabin / utilities on
0:05 voice recorder check
0:06 turning on (aligning) IRS
0:10 Fire checks (Bell, loop, fault)
0:12 Extinguisher checks (3 bottles)
0:13 Cargo extinguisher checks
0:15 Oxygen mask check (demand only / emergency)
0:20 Audio Selector Panel setup. Buttons on the top are the options for transmitting.
Knobs on second row are options for listening.
0:30 FMS setup (also part of aligning IRS Navs)
0:34 Manual route entry. Left side are the airways (roads) and right side are the
fixes (intersections)
0:40 Arrival Setup. Left side are the STandard ARivals. (STARS) Right side are the
actual runways approaches.
0:44 Fuel pumps on.
0:45 engine driven and electric hydraulic pumps on. Note: several operators leave
the A side off for push back because nose wheel steering is commanded by
A-Side hydraulics. There is also a bypass on the gear as an alternative to
shutting off the A-Side.
0:48 overspeed warning test. (clacker is what goes off if you overspeed the plane
and is an indication of a good check)
0:50 window heat on (1 for each window)
0:52 AC setup
0:54 setting cruise altitude on the pressurization panel
0:55 setting landing altitude
0:58 Flight director on. ("MA" is master. It's the copilot's leg to fly)
1:01 Autobrake to RTO (Rejected Take Off)
1:06 cockpit light check
1:10 transponder to 2 (It's the copilot's leg)
1:19 GPWS check
1:30 Hyd pumps off (see above)
1:31 AC packs off
1:33 beacon on
1:35 pilot cooling fan #2
1:58 ignition switches to ground (starts the engine turning)
2:02 fuel switch on (introduces fuel to the engine). Also how you shut the engine
down.
2:06 N2 rotation - speed at which the engine is turning. Fuel is typically
introduced at 25% N2. Too early / slow and you might get a hung start.
Or a hot start.
If you just want to start the engines, taxi, and take off for a joyride (completely violating company/FAA policy), the steps are quite a bit less although still involved, depending on how old the aircraft is and the level of automation it has. This video seems to show a 737-800 or later, which is pretty new and most likely has a system that with one or two buttons handles the bleed air/ignition/fuel sequence of starting a turbine.
Source: me, for commercial airline (b737-800)
If you skip the ground align (the system can align in the air; it just takes longer and is a bit less accurate but the latter isn't modeled in the sim), someone that knows what they're doing can have the plane rolling down the taxiway in ballpark 90 seconds.
I'm not an A-10 pilot, but I have a couple hundred hours pretending to be one in DCS. ;)
edit: I'm seeing things it was just one hand.
Having spent 18 years trying to design software and websites to be idiot-proof, to me it looks like they could seriously use some human-friendly UI and procedure design. When the stakes are as high as they are during a packed commercial flight, it would seem to me that maximum possible simplicity would be the goal. Perhaps a "flight checklist wizard". It is possible to enable the granular control that pilots need without making them this complex.
And then, the testing environment changes. This time, it's two machines (can you tell this happened?). Not four. At least with doing this huge checklist each time, I know the steps well enough to adapt the procedure (okay, I need to mentally translate machine "foo and bar" to "snafu"). Automated, it would require extensive testing just so we can run our tests ...
(Unfortunately: this Horn is the same Horn as the cabin altitude warning Horn, having a big part in the mentioned greek airline incident)
In fact, ergonomics was started by research during WW2 to reduce airplane accidents caused by human error. There's a reason flying is the safest mode of transportation today, and efforts in ergonomics play a big role. For example, the gears are placed in standardized locations / have standardized shapes to prevent pilots from using the wrong ones while in panic mode.
A primary concern of automating error detection is that it leads to laziness by cognition of least resistance. In the real world, pilots will simply rely on the machine to give them feedback rather than knowing what's fundamentally wrong themselves. This is dangerous because mastery goes away and you end up with experienced, routine button-pushers that slap a 777 into a seawall or trim some trees.
The other concern is zero incident complacency. If there were a "chaos monkey"-like system that could continuously introduce fire drill challenges, while being able to reveal themselves as authentic or not, would keep pilots alert and grade reactions before something larger happens. This is an instance where automation by purposeful fault injection might be able to maintain reaction fitness more consistently over time.
FADEC notwithstanding, there are easily a half dozen different ways to start the engines even in normal circumstances, depending upon what ground services are available, ex: Ground cart vs APU, crossbleed air, electric vs air(aircraft dependent).
Baby steps. Another 5-10 years, and flight will be entirely a tech issue. Example: Airbus A380 fly by wire.
"Incorporating fly-by-wire controls on the A320 allowed Airbus to tailor the aircraft’s computer flight control laws – adapting them to the pilots’ side-stick controllers that replaced previous-generation control yokes – while also introducing flight envelope protection. As a result, flight safety was greatly increased and the crew’s workload was reduced."
Now, that's a lot of marketing fluff, but aircraft manufacturers continue to abstract away flight workload. Navigation relies heavily on GPS, and once the FAA's NextGen ATC system is fully implemented (ADS-B, etc), you'll see victor airways give way to direct routing. Point, click, navigation done. Flight separation can be automated as well with ADS-B. Aircraft can already perform fully automated landings using autoland at Class III ILS runways (which will make way for cheaper, more precise Local Area Augmentation System, which is just a fancy DGPS/RTK precision positioning system for airports).
I used the A380 as an example, but the same could be said for Boeing's Dreamliner. Tech moves slower in aircraft because of FAA regulations and conservative views (its lives we're talking about of course), but its getting there.
I would be surprised if you didn't have fully automated flights (take off, cruise, landing) in 5-10 years using the same guts from UAVs. You'll still have a pilot onboard, but their workload will be minimal.
Many modern airliners actually have computers which will display common checklists and check off items that have been completed automatically. The reason they don't make this fully automated is because a malfunction in the computer, or a bug in the software, or a situation the checklists did not forsee could be disastrous. Having the pilots in the loop adds an important sanity check.
Note also that a lot of the steps in the procedure are testing warning lights and sounds, which really does require a human in the loop to listen or look at the alarm in question to verify it's going off.
What is up with that?
[1] http://www.youtube.com/results?search_query=golfcharlie232&o...
I'm mostly impressed with how simple things are, given the number of components involved. Seems to be a fine line between "banks of idiot lights" and flying an airliner with a zillion gauges and dials. There's a crapload of stuff you need to know about electrical systems, hydraulics, backup systems and self-diagnostics . . . not to mention actually flying the crate.
That is a pretty new 737 (someone speculated 737-800). Note the flat panel primary displays (color LCDs), that is the tip-off that this is pretty new.
P.S. There is a small piece of me in the FMS.
Glass cockpits have been around for some time now. Also many older 737s (at least with US-based airlines) have been retrofitted with newer equipment. For example, all of SWA's 737-300 series aircraft (the oldest in their fleet) have been upgraded to glass cockpit controls.
The original Dual FMS was a Motorola 68040 (the predecessor FMS was the TI TMS9900 architecture implemented in bit-slice processors(!), later an ASIC, because the TI 9900 was a bust. The original code was Fortran, with the Dual FMS it was ported to Ada.
The development environments back in the late 1980s, early 1990s was custom hardware and in circuit emulators (ICEs). The ICE plugged into the processor socket and emulated the processor but with breakpoints and trace. The 68040 was about the end of the line where this worked (the head of the 68040 ICE was pretty large. There were no "eval" boards to develop code on... we wrote code and waited for the hardware guys to get the first article built. When the hardware guys got done with the initial checkout on the first article, we got the system and started making the code work.
Once we got the hardware, software development was a lot like now: start with basic functionality, cross your fingers, burn and learn. With the ICE, "burning" was faster because you substituted ICE RAM for the target flash and the trace of the ICE was a lot more useful than today's JTAG-based debuggers - you could see everything for the last 1K-4K instructions, including the actual states of the pins of the processor.
The development lab had real equipment (e.g. the Control Display Units (CDUs)) and a lot of simulated I/O. The simulated I/O was driven by a flight simulator running on a Dec MicroVAX. The flight simulator simulated the flight characteristics of the 737, responding to the commands given by the FMS. Since I was mostly low-level, I didn't do much with the flight simulators, but I could enter flight plans (typically "company routes" which are pre-canned airports, runways, and waypoints) and go through all the motions of flying. The simulator could speed up time to save time waiting for things to happen. IIRC, 4x real time was about as fast as you could go because the systems would go wonky.
[1] http://en.wikipedia.org/wiki/Avionics_Full-Duplex_Switched_E...