I like airplanes and dramas with happy endings. So I followed the story of Captain Chesley “Sully” Sullenberger and his handling of US Airways Flight 1549 when a flock of birds disabled both engines forcing him to land in the Hudson River.
I enjoyed the recently released movie, Sully, starring Tom Hanks, which brought the story to the big screen. Aside from the actual event, much of the movie was centered on the review of the incident by the National Transportation Safety Board.* Of interest to me were two components: simulations and forensics.
I’ve developed and built simulators which simulate Hewlett-Packard’s LaserJet printers. Under some conditions, it was hard to make it real-life accurate. I’ve had similar experiences to the movie’s story line where the simulator said they could have made it back to an airport, which contrasted with Captain Sully’s expert opinion. Captain Sully twice asked the review board to oversee the simulations to determine why they were different but, per their procedures, he was not allowed. Without giving away too much of the movie, let me just say that in the end, the simulator was not an accurate representation of that particular real-life scenario.
Replicating real-life situations is a definite challenge for engineers developing simulators. A line in the movie hits this point home. The review board said, “The engineers said you could have made it.” Captain Sully responded, “Engineers are not pilots.”** This emphasizes the importance for engineers to involve domain experts and users in simulation development.
A challenge for engineers developing simulators is to account for all possible scenarios. But, this was a situation that the pilots had not been trained for. Captain Sully had to do things that were against protocol. The review board said, “But that’s unprecedented.” To which Captain Sully responded, “Everything is unprecedented until it happens the first time.”
Simulator developers and users need to recognize that it’s impossible for simulators to account for all possible scenarios when human beings and the natural world are involved.
In the movie, the review board also examined the sensor data logs which indicated that the left engine was still somewhat functional and could have been used. Captain Sully was sure the left engine was dead. In my forensic experience as an expert witness, I don’t take all data as fact without some corroboration. In my mind, I immediately said that the sensor or some module was probably putting out bad data, especially given the other evidence they had. But they never questioned the sensor or its data. Only later, after they retrieved the engine from the bottom of the river and examined it, did they finally admit the engine was dead in spite of the sensor data. When doing forensic work, or even trying to troubleshoot a misbehaving product or device, collected data must be not be treated as 100% reliable or accurate.
Watching Sully was a good refresher of some good engineering practices.
* Some say that the portrayal of an adversarial NTSB in this movie was not accurate. Whether or not the events and dialog as portrayed in the movie were factual, there are some good lessons and insights to be gained.
** These movie quotes are to the best of my recollection (after watching it in the theater twice) since the DVD versions are not out yet.
P.S. Another movie that comes to mind where good engineering turned a potential tragedy into a happy ending: Apollo 13, which also starred Tom Hanks.
Images from Wikimedia Commons.
Gary Stringham is an expert witness and consultant in hardware, software, and firmware. He can be contacted at 208-939-6984.
