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.
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.
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.
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.
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
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.
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.
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
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.
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
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
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.
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.
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
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.
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
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.
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.
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
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.
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.
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.
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.
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
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
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.
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
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.
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.
to today’s awardees; we at the NTSB wish you great success in the future.