There was a good thread on the /r/flying subreddit discussing this procedure yesterday. Specifically, poster /u/veritasiness outlined the entire procedure step by step  which I'll cut and paste here:
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
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
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.
As someone who has designed avionics for experimental aircraft and rockets, one of the satisfying highlights, like the salty sticky bits as you mop up the plate of a roast, is designing and building the switch panels.
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!
Private pilot here (who's also ridden in some full-scale airliner flight sims). A lot of the procedures in the video are going through checklists to test the various instruments and systems, both normal and emergency ones, as well as entering the route in the flight computer (used by the autopilot). This is what real pilots on real flights have to do.
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.
I wish there was a global YouTube switch to filter out all flightsim videos. I don't know how many times I've search for xxx landing at yyy only to find some PC flightsim with annoying music in the background.
It's actually possible to compress that startup significantly too. The most time-consuming part of the A-10C's start up process -- by far -- is the roughly 4.5 minute wait for the navigation system to align.
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. ;)
I'm still wondering how the camera which seems to be held in his hand and then it shows him using two hands to do one check, and it looks like it's in front of his face not held by someone else off to the side; Google Glass?
Well.....what could possibly go wrong there? There have been several air disasters over the years that resulted from a failure to flip the right switch or check certain settings, either in-flight or pre-flight. A Greek crash where the pilot forgot to flip the auto-pressurization switch, killing most on board before the crash itself, comes to mind. This video leaves little wonder why these things happen.
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.
I don't know. At work, I'm responsible for the regression test. I wrote the regression test. And I have a check list with 52 items required to run it (step 50 is actually running the test, the next item is making sure it's running, and the 52nd item is "walk away for the next five hours"). Could it be simpler? Yes, but it would require even more setup (since it involves generating several datasets that are copied to four machines), making sure configuration files are up to date (less an issue now than when we first started), and could involve restarting named (since one of the datasets is a particular zone file), and then starting up the various programs across all four systems.
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 ...
The difference is that if you accidentally skip one of these steps, you won't destroy a $50M+ piece of equipment, devastate 100+ families, and/or disable an airport or neighborhood for days while rescuers collect the body parts of all the people you killed. Complexity is the enemy of humans in stressful situations. Where lives and tens or hundreds of millions of dollars are on the line in a zero-fail environment, I would strive for simplicity.
Not saying you're entirely wrong, but there's a difference between incidental vs necessary complexity, and a web UI is not even remotely similar to an avionics dashboard. There might be something we software people could teach those in avionics, but I'd imagine the reverse is actually much more the case.
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.
Some modern airliners have computer-based checklists that will verify that all checklist steps were completed correctly for you. They also have alarms that will go off if the aircraft configuration is egregiously wrong on takeoff (eg, http://www.youtube.com/watch?v=hOqMttyD_Zc). With older or smaller jets, however, some of these safety features might be missing or less sophisticated, so it's more on the pilots to correctly execute the checklist.
Automation sounds great, but it must be followed-up as to how it's used or abused in the real world in order to maintain air safety.
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.
What this video doesn't show is the multiple redundant checks that are done, and the warning systems that sound if something is out of place (like the one that the Helios pilots misunderstood). Newer airplanes do have more human friendly designs and more automation, including electronic checklists. For existing cockpits, they are usually only upgraded when serious design flaws are discovered. But that doesn't happen often.
I was also thinking about this. Even if the controls and procedures remain completely unchanged, it should be possible to issue warnings when things were done wrong. In fact I'd be surprised if this wasn't at least partially implemented already.
Next to some planes having electronicaketen checklists; some "older planes" have a somewhat simpler form of digital checks. For example: the 737-800 has a take-off configuration warning (a Horn) When the thrust levers are advanced without having set a proper flap setting for take-off.
(Unfortunately: this Horn is the same Horn as the cabin altitude warning Horn, having a big part in the mentioned greek airline incident)
Cool vid, but calling that a 'start up' is a little misleading. There's much more going on there than starting the engines. Modern turbine engines are pretty automated and don't require much more than the push of a button (starter) and flip of a lever (fuel) to start.
>Modern turbine engines are pretty automated and don't require much more than the push of a button
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).
It's not because "start up" doesn't mean they're just turning on the engines, but means they're running through the start-up checklist. This is far more than just starting the engines, and includes configuring the plane and testing to make sure essential systems are okay.
What happens if the computer malfunctions in mid-flight?
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.
Some of the steps look like they're checking that various warning lights and systems work correctly, which needs a human in the loop. I guess there are other bits which require human decisions - e.g. you can't start the engines without visually checking that no-one is standing near them. Finally, any automation is another possible system that could fail, so it needs more examination and testing.
"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.
I'm curious about something though, the author "golfcharlie232" has a great youtube channel  with lots of cool videos, but this one is copied off youtube into its own little player. So basically its taking ad revenue away from this guy (I presume he keeps the ad revenue).
There are a bunch of similar YouTube videos made by the Baltic Aviation Academy.
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.
A couple of people have hinted at the question, but I'll ask outright in case someone can answer: How quickly could you just start everything up sans checklist in an emergency? I thought I saw a couple of switches which actually started the engines, but I assume that at least some of the preparatory steps are required.
All of it. The pilot is going through a checklist. The checklist is not going to have unnecessary steps in it. When pilots don't follow the checklist sometimes they die, so they are pretty religious about following the checklist.
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.
> Note the flat panel primary displays (color LCDs), that is the tip-off that this is pretty new.
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.
Awesome!!! Never knew it actually operates over TCP/IP, I always assumed some custom protocol/ARINC interop between the two units. Can you perhaps elaborate in some way on the dev environment When working on "stuff like that"? :)
New systems (not the 737 FMS) use ARINC-664 - UDP/TCP/IP/ethernet with all the good parts disallowed. :-) The original Dual FMS predates ARINC-664.
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.