Skip Ribbon Commands
Skip to main content
Bookmark and Share this page


Remarks to RTCA 2015 Global Aviation Symposium Annual Awards Luncheon
Christopher A. Hart
Washington, DC

Thank you, Carl (Esposito) for that kind introduction, and my thanks to RTCA for inviting the National Transportation Safety Board to speak today. And congratulations to today’s awardees. I was reading through the program, and I saw how many issues some of the significant contributors and outstanding leaders have been tackling.  What a tribute to the industry that so many companies and individuals are willing to volunteer their time and resources to work on these important issues.
I am Christopher Hart, and it is my privilege to serve as the Chairman of the National Transportation Safety Board, or NTSB. As many of you know, the NTSB investigates accidents and incidents in all modes of transportation, determines what caused the accidents and incidents , and makes recommendations to help prevent them from happening again.
Like RTCA, we conduct our deliberations in public view. Like RTCA, we often “advise” the FAA. The difference is that our advice is in the form of recommendations, based on lessons learned in accidents. And in addition to regulators such as the FAA, we issue recommendations to state or local governments, manufacturers, operators, labor unions, trade associations, or anybody else who can help to improve safety. We are not a regulator, and we can’t require anyone to follow our recommendations, but it is a testament to the quality of our amazing staff of investigators and analysts that more than 80% of our recommendations are nonetheless acted on favorably.
In aviation, RTCA and NTSB fulfill somewhat complimentary roles. You provide the best technical advice possible to the FAA – sometimes in response to past NTSB recommendations. We provide feedback to make the system even safer, if something does go wrong.
Today I’d like to talk to you about some of the lessons that we have learned from accident investigations and what that tells us about the future of aviation safety.
But first, kudos to RTCA for the work that Special Committee 225 has done on the design, certification, and construction of permanently installed rechargeable lithium-ion batteries and battery systems.
That committee has shown amazing flexibility and collaboration to address the recommendations that we issued in 2014, based on our investigation into the January 7, 2013, battery event in Boston.
In that event, cleaning personnel discovered smoke in the aft cabin of a Japan Airlines Boeing 787 that was parked at a gate at Logan International Airport. A maintenance manager in the cockpit observed that the auxiliary power unit (APU) – the sole source of power to the aircraft at the time – had automatically shut down. Shortly afterward, a mechanic opened the aft electronic equipment bay and found “heavy smoke” and a “small flame” coming from the APU battery case. No passengers or crewmembers were aboard the airplane at the time, and fortunately there were no injuries to the maintenance or cleaning personnel who were on the airplane.
We recommended that the FAA develop a thermal runaway test for permanently installed rechargeable lithium-ion batteries, with a setup that replicates the battery’s installation on the aircraft and is conducted under conditions that produce the most severe effect. One of the important lessons learned during the NTSB’s investigation of the Boston event was that thermal runaway propagation from one cell to others in the battery could be significantly affected by the installation, design, and range of operating conditions. 
So, running a test that didn’t take these factors into account might not reveal the true safety risk from a single cell in the battery going into thermal runaway.  Part of the solution was incorporating these lessons learned into the existing DO-311 standard, and another part was developing guidance for aircraft manufacturers regarding installation and operational use conditions.  We also recommended broader collaboration, including with the other Government agencies and U.S. national labs that have experience with safety evaluation and testing of such batteries.
But this presented a problem – SC211, the RTCA committee that had written the Minimum Operational Performance Standards, or MOPS, for Rechargeable Lithium-ion Battery Systems installed on airplanes and in avionics, was no longer active. So SC225, which had been working on small and medium format Lithium-ion batteries, took over regarding the concerns that we raised in our recommendations.
RTCA’s public and collaborative process resulted in a committee comprising not only aircraft and battery manufacturers, but also the Army, the Navy, the Air Force, NASA, the National Fire Protection Association, the Airline Pilots Association, The Association of Flight Attendants, American Airlines, Delta Airlines, FedEx Express, foreign regulators, and others.
You also did something else that was very important – you kept communication open with the NTSB. When we make recommendations, we seek to recommend what needs to be done, but not how, in order to avoid becoming prescriptive.  If we became prescriptive, we might end up investigating our own recommendation, which would undermine our investigative independence and objectivity.  Hence, while we carefully avoid taking an active part in developing a specific standard, we are more than willing to brief RTCA committees on investigation lessons that we have learned or NTSB recommendations that are relevant to the committee's work.
So why am I offering these kudos? Not for the final product, which is still pending, but for recognizing the value of broad collaboration to solve the problem.
When I talk about the value of collaboration in improving aviation safety, I often use the example of the Commercial Aviation Safety Team, or CAST. That amazingly successful collaborative effort brought together the FAA, industry, organizations representing employees, and others.
Aviation’s fatal accident rate had declined for decades, but in the early 1990’s it reached a plateau. The goal of CAST was to further reduce the fatal accident rate by 80% in 10 years. Through collaboration, the CAST process exceeded this goal.
The moral of the story, as I often say, is that everybody who is part of the problem should be part of the solution, and that’s what CAST did.
An important part of the CAST success was how heavily the FAA relied on RTCA products to implement centerpieces of the CAST improvements. In the early days of CAST, for example, RTCA developed the standards that enabled terrain avoidance warning systems and minimum safe altitude warning systems, to reduce controlled flight into terrain accidents.
So kudos to RTCA for its work that has helped CAST.  And because you’ve been forming  committees from around the world to solve technical and policy problems since 1935, kudos to RTCA for its role in bringing down the commercial aviation accident rate for more than half a century before CAST as well.
The collaborative process, which has been so successful for both RTCA and for CAST, reflects the fact that an airplane is a complex system that involves multiple hardware and software subsystems that affect each other because they are coupled. In my earlier example, a battery as installed poses different risks compared with a battery in isolation – and as we know the totality of systems of which the battery is a part can be much more complex than that.
Complex coupled systems demand system solutions not only for their hardware and software separately, but also for all of these subsystems working and interacting together. And as modernization of the national airspace system (NAS) moves forward, we must be ever-mindful that these complex systems – airplanes – are themselves sub-systems of the NAS.
One of the major challenges of complex systems is that one subsystem of the system can affect another seemingly unrelated subsystem in unexpected ways. And we have to stretch even more to understand these multiple couplings and interactions in a system as complex as the whole NAS.
But there is yet another complex subsystem to consider, one which must work seamlessly with other complex coupled subsystems: the liveware, or the people using the technology, whether they interface with automation in the cockpit or with an air traffic control screen.
One recent accident illustrates how investigators like those at the NTSB, might find issues in all three systems - the hardware, the software, and the liveware – and in the interfaces between them.
In 2009, Air France flight 447 crashed into the Atlantic Ocean while enroute from Rio de Janeiro to Paris.
That accident occurred at night, when the airplane was in Instrument Meteorological Conditions, in or near thunderstorms and in turbulence, in large quantities of supercooled water, and flying in "coffin corner," that is, with very little plus-or-minus airspeed margin around their cruise airspeed.
In these circumstances, the pitot tubes - the tubes that protrude from the airplane to measure the airspeed, based upon the dynamic pressure of the air that is hitting the tubes - became frozen over in supercooled water that turned into ice.
When the pitot tubes froze, the aircraft computers no longer had airspeed information. The loss of airspeed information caused the loss of, among other crucial systems, the autopilot, the automatic throttle, and the protections against exceeding a safe angle of attack.
Numerous error messages were displayed to the pilots, and for unknown reasons, one pilot pulled back the control stick, commanding nose-up and causing the airplane to enter an aerodynamic stall. The pilots were not able to recover from the stall, and the aircraft ultimately crashed into the ocean.
One of the major hardware problems was that the three independent pitot-static systems - independent for redundancy - were not actually redundant because they were all taken out by a common cause: icing.
This problem had been encountered before, and a retrofit of more robust pitot tube heaters was underway for the entire fleet, but it was not an emergency retrofit because other pilots had recovered successfully from this problem, and the accident airplane itself was soon due to be retrofit.
The software problems included that all of the airspeed-dependent systems stopped functioning immediately upon losing the airspeed information, rather than transitioning gradually; and that the error message displays revealed no cause-and-effect relationship, i.e., that the loss of airspeed information was the reason for the failure of several other systems. The pilots were apparently unable to determine, in the startled moment, exactly what caused so many error messages to suddenly appear.
The liveware problem started with the fact that the pilots were startled - they were flying along on autopilot and all was well, when suddenly many error messages appeared, and they immediately had to take over and fly the airplane manually. They did not understand the system well enough to be able to figure out what was happening, and they had never before experienced a loss of airspeed event in cruise, even in training. Last but not least, manual flight at cruise altitude is illegal in most parts of the world where they fly, and hence the pilots had never before flown the airplane manually at cruise altitude, even in training.
As RTCA well knows, automation and other new technologies have led to increases in both efficiency and safety throughout the history of aviation. But the systems are not perfect, so the continuing challenge is how to assure that if – or rather, when -- something goes wrong, the system fails in a safe way instead of catastrophically.
Flight 447 is but one of many accidents that demonstrate that the aviation community is still struggling with hardware/software/liveware system issues.
That’s why this is an opportune moment to congratulate RTCA on forming Special Committee 233, Addressing Human Factors/Pilot Interface Issues for Avionics. In every accident, investigators study the human, the machine, and the environment, and the relationship between them – as this Air France 447 example illustrates.
So kudos for recognizing the pivotal role that the interface of software, hardware, and liveware will continue to play as new and more sophisticated avionics come on-line.
SC233 is tasked with recommending a process for evaluating the human factors/pilot interface aspects of avionics, and with submitting an overview of some prevalent, recurring human factors/pilot interface issues that may aid the early identification and resolution of these issues as part of the design and evaluation process.
The goal of the committee is not to develop new performance standards, operational standards or other requirements.
Rather it is to develop a recommended evaluation process, and a list of commonly seen human factors issues. The resulting document is intended to raise the level of awareness about human factors to facilitate the identification and resolution of such issues by system designers and developers, as well as by FAA Flight Test Pilots, Engineers and Human Factors Specialists within the FAA Aircraft Certification Offices as part of their review and approval process.
The interface between the hardware, the software and the liveware occurs wherever there is a human in contact with any electronic system in the NAS. The challenge is not only to optimize the safety and efficiency of every subsystem, but also to collaboratively address the ways in which the subsystems affect one another – the hardware, the software, and the liveware.
Note that the RTCA’s challenge in this regard is actually more difficult than the NTSB’s challenge, for two reasons.  First, because RTCA’s standards come before an accident, which means the RTCA is trying to predict the myriad of ways things might go wrong.  We, on the other hand, are looking at accidents or incidents in which things have actually gone wrong, so we always have the benefit of hindsight.  Second, as I noted previously, we recommend what needs to be fixed, but RTCA is tackling the more difficult challenges of determining exactly how to address the issues.
This is why expanded collaboration between RTCA and the NTSB can be a win-win for both organizations. As you go about your work, I urge you to view the NTSB’s aviation safety staff as a resource. As I said, while we avoid actively participating in the development specific standards, we are eager to brief committee members on lessons learned in our investigations, or NTSB recommendations, which are relevant to the committee's work.  Conversely, the more we know about what is actually happening in the real world, such as by working more closely with RTCA, the more realistic and meaningful our recommendations will be.
For all your work to advance safety over the years - including, of course, the work of this year’s awardees - I thank you. As you seek out the most effective and efficient solution to technical problems, I commend your continuous recognition that safety is paramount.
For those of you who are involved in the process of evaluating the design of the human-machine interface, I hope that your process captures this engineer’s paraphrase of what President William Howard Taft said about writing: don’t design to be understood; design so that you can’t be misunderstood.
The more that your processes result in avionics that cannot be misunderstood, the more likely we are to continue enjoying improvements in aviation safety. That would be a good thing.
Congratulations to today’s awardees; we at the NTSB wish you great success in the future.