Re: [SystemSafety] 737 tail strike caused by typo on a tablet

From: Matthew Squair < >
Date: Sat, 21 Nov 2015 18:54:37 +1100


Well I took a stab at deconstructing the ATSB report.

http://criticaluncertainties.com/2015/11/21/error-ipads-and-attribution/

I think they miss a number of significant issues, very much a 'try harder' response. Which always works...

On Thu, Nov 19, 2015 at 7:43 AM, Matthew Squair <mattsquair_at_xxxxxx wrote:

> The assessment of the second error as a 'transposition' error committed by
> the second pilot seems dodgy to me.
>
> Matthew Squair
>
> MIEAust, CPEng
> Mob: +61 488770655
> Email; Mattsquair_at_xxxxxx > Web: http://criticaluncertainties.com
>
> On 19 Nov 2015, at 6:44 AM, Gareth Lock (Human in the System) <
> gareth_at_xxxxxx >
> Interesting discussion and one which exemplifies the Efficiency
> Thoroughness Trade Off (ETTO) which exists.
>
> The most thorough (and safe?) way would be to have two pilots to do two
> individual calculations using different media (both electronic but
> different algorithms, or manual and electronic) and then do the same in the
> other medium, then cross compare to ensure that the answers are the same.
> If not, go back in and try to work out where the error was. This would have
> been the only way to trap the error from this incident due to the same
> answers but different modes of failure (
> http://atsb.gov.au/media/5727742/ao-2014-162_final.pdf). This has a time
> implication as highlighted by Klaus below.
>
> However, in the real world, time is a real driver with many low cost
> airlines only at the gate for 30-60mins before leaving again and given the
> massive number of take-offs and landings taking place with similar process,
> and the lack of accidents, the airlines are making a calculated risk that
> the current methodology is acceptable. The regulators must also think this
> is the case too.
>
> Despite all of the calculations being correct, you can have issues with
> crew taxing to the incorrect part of the runway, being convinced that they
> are at the end of the runway because of the visual cues present, turn
> around and take-off some 2000ft further into the runway than they
> thought...as they passed the upwind threshold thinking that was quicker
> than thought and then looking on Google Maps to see that the taxi chart
> didn't quite represent the real world...!! An incident report was filed by
> the crew so others could learn from their mishap.
>
> Regards
>
> Gareth Lock
> Managing Director
> Human in the System Consulting
>
> M: +44 7966 483832
> E: gareth_at_xxxxxx > W: http://www.humaninthesystem.co.uk
> T: _at_xxxxxx >
> Skype: gloc_1002
> WhatsApp: +44 7966 483832
>
> <Banner-signature.png>
>
>
> This email and any files transmitted with it are confidential and intended
> solely for the use of the individual or entity to whom they are addressed.
> If you have received this email in error please notify the sender by email
> or telephone. This message contains confidential information and is
> intended only for the individual named. If you are not the named addressee
> you should not disseminate, distribute or copy this e-mail. Please notify
> the sender immediately by e-mail if you have received this e-mail by
> mistake and delete this e-mail from your system. If you are not the
> intended recipient you are notified that disclosing, copying, distributing
> or taking any action in reliance on the contents of this information is
> strictly prohibited.
>
>
>
> SPRIGGS, John J <John.SPRIGGS_at_xxxxxx > 18 November 2015 at 10:25 via Postbox
> <https://www.postbox-inc.com/?utm_source=email&utm_medium=sumlink&utm_campaign=reach>
>
> José beat me to it; I was writing something similar.
>
> One point I have in addition is that the person doing the pen and paper
> check should not be the person who used the tool to do it. When there is a
> discrepancy, the checker must not assume that the senior person (no doubt
> the one with the iPAD) is correct and that (s)he has made a mistake
> somewhere in the working. The two people should swap methods and do it
> again.
>
>
>
> John
>
>
>
> *From:* systemsafety-bounces_at_xxxxxx > mailto:systemsafety-bounces_at_xxxxxx > <systemsafety-bounces_at_xxxxxx > Faria
> *Sent:* 18 November 2015 10:18
> *To:* Klaus
> *Cc:* <systemsafety_at_xxxxxx > <systemsafety_at_xxxxxx > *Subject:* Re: [SystemSafety] 737 tail strike caused by typo on a tablet
>
>
>
> >> "The calculation is double checked using pen and paper, and so two
> dissimilar faults were necessary to invoke the failure vector."
>
>
>
> Again and again, safety arguments include claims about human/manual
> behaviour that should urgently be re-visited (not to simply say, ruled out).
>
>
>
> You are a system operator; You have a machine that calculates a value for
> you; You use it and get an answer; You go and calculate it manually "to
> confirm"; How biased is you manual calculation already?
>
>
>
> Simple and harmless personal story: I was 14 years old, doing a math test.
> For one of the exercises, I was able to mentally figure out the result
> (value 4), before writing down the equations. Along the writing, I made a
> mistake and end up with a expression resulting in square root of 36. My
> brain didn't even notice and I just wrote down that SQRT 36 equals 4 and
> moved to the next exercise.
>
> When you're in a hurry, 16 isn't "that different" form 36 when you already
> "know" the result, and are not really doing the calculation.
>
>
>
> Jose'
>
>
>
> On Wed, Nov 18, 2015 at 10:13 AM, Klaus <klaus_sievers_at_xxxxxx >
> Well, hm...
> I fly 747 since 1987. Copilot, Captain...
> Distractions have increased, procedure design hasn´t quite
> kept up with all the things going on during the last minutes
> before departure.
>
> 20 years back, the data for takeoff were calculated by hand,
> using tables, and everything was ready 15, 20 minutes before
> pushback.
>
> Today, preliminary calculations are done 15, 20 minutes
> before pushback, but then updated with the latest info of
> + or - 5 passengers, a bit of cargo - whatever. THEN, with
> sheduled time of departure coming near, then things are
> recalculated and finally transferred, manually, into the airplane
> computers .
>
> Distractions ? You better be immune to them - which no-one
> can really be.
>
> About the 737: looks like a 10 ton error to me, maybe 15 % of
> takeoff-weight. May have been contributing, but I have doubts
> it was the main reason for the tail-strike.
>
> 747s , which are much larger than 737, have been known to
> scrape the runway, yes, but then the error was more than 25%
> of takeoff weight. 2xx tons instead of 3xx tons....
>
> Solution: try to keep a calm working athmosphere in the cockpit
> and do as much preparation as can be done : every moment counts.
> And: do the checklists, the required crosschecks.
>
> Hope that this was interesting,
>
> Best,
> Klaus Sievers
>
>
>
> Am 18.11.2015 um 09:01 schrieb Peter Bernard Ladkin:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Deja vu all over again.
> http://www.rvs.uni-bielefeld.de/publications/Papers/LadkinHESSD2009.pdf
>
> PBL
>
> On 2015-11-18 06:57 , Heath Raftery wrote:
>
> This news article is likely to be of interest to the list members. A
> jumbo's tail struck the
> runway on take-off, and root cause was found to be an incorrect take-off
> weight entered in the
> thrust parameter calculator. The fact the calculator is an app running on
> an iPad may or may
> not be important to the story, but it does give it that everyday appeal.
>
> The calculation is double checked using pen and paper, and so two
> dissimilar faults were
> necessary to invoke the failure vector. Is there anything more that can
> reasonably be done to
> avoid this safety issue?
>
>
> http://tech.slashdot.org/story/15/11/16/174213/737-tailstrike-caused-by-typo-on-a-tablet
>
>
>
> Prof. Peter Bernard Ladkin, Faculty of Technology, University of
> Bielefeld, 33594 Bielefeld, Germany
> Je suis Charlie
> Tel+msg +49 (0)521 880 7319 www.rvs.uni-bielefeld.de
>
>
>
>
> -----BEGIN PGP SIGNATURE-----
>
> iQEcBAEBCAAGBQJWTDBlAAoJEIZIHiXiz9k+ChIH/0E1rHDycXUB4ctrzvWWWq/z
> gR2Y2krA9+MiypWmfwgkcgeKhvxKICtLk4KOee3bqZOaRZRNlj9lhvzT1tfoVyo9
> diIr5S+EqZnCy0MjOzeUJVAw46em0L9AhvsQtys3Xl0euNOb+41hB9kecfLOfSHp
> wJnnxg39++oOKV7fkM8Dzb62p115VHiSEXjle5UzcbdIAuX/IkO9v4h6hJUZsWRj
> JOkBnAr0prUrhmpR3xe9uLK3WZ995nNreBOX6M2LGA8hDtOshniBRUsEQLJ2ucC9
> kpqtHDUnitm90x+3L7P52UcwoTN/P6WhI986pmNoDHiL3ZdMUAZ/KVxlPcJlLGs=
> =Meqf
> -----END PGP SIGNATURE-----
> _______________________________________________
> The System Safety Mailing List
> systemsafety_at_xxxxxx >
>
> _______________________________________________
> The System Safety Mailing List
> systemsafety_at_xxxxxx >
>
>
>
> --
>
> --
>
> *José Miguel Faria*
>
> *Educed *- Engineering made better
>
> t: +351 913000266
> w: www.educed-emb.com
> e: jmf_at_xxxxxx >
>
>
>
> ------------------------------
> If you are not the intended recipient, please notify our Help Desk at
> Email Information.Solutions_at_xxxxxx > or use this email or attachment(s) for any purpose nor disclose their
> contents to any other person.
>
> NATS computer systems may be monitored and communications carried on them
> recorded, to secure the effective operation of the system.
>
> Please note that neither NATS nor the sender accepts any responsibility
> for viruses or any losses caused as a result of viruses and it is your
> responsibility to scan or otherwise check this email and any attachments.
>
> NATS means NATS (En Route) plc (company number: 4129273), NATS (Services)
> Ltd (company number 4129270), NATSNAV Ltd (company number: 4164590) or NATS
> Ltd (company number 3155567) or NATS Holdings Ltd (company number 4138218).
> All companies are registered in England and their registered office is at
> 4000 Parkway, Whiteley, Fareham, Hampshire, PO15 7FL.
> ------------------------------
> _______________________________________________
> The System Safety Mailing List
> systemsafety_at_xxxxxx > José Faria <jmf_at_xxxxxx > 18 November 2015 at 10:18 via Postbox
> <https://www.postbox-inc.com/?utm_source=email&utm_medium=sumlink&utm_campaign=reach>
> >> "The calculation is double checked using pen and paper, and so two
> dissimilar faults were necessary to invoke the failure vector."
>
> Again and again, safety arguments include claims about human/manual
> behaviour that should urgently be re-visited (not to simply say, ruled out).
>
> You are a system operator; You have a machine that calculates a value for
> you; You use it and get an answer; You go and calculate it manually "to
> confirm"; How biased is you manual calculation already?
>
> Simple and harmless personal story: I was 14 years old, doing a math test.
> For one of the exercises, I was able to mentally figure out the result
> (value 4), before writing down the equations. Along the writing, I made a
> mistake and end up with a expression resulting in square root of 36. My
> brain didn't even notice and I just wrote down that SQRT 36 equals 4 and
> moved to the next exercise.
> When you're in a hurry, 16 isn't "that different" form 36 when you already
> "know" the result, and are not really doing the calculation.
>
> Jose'
>
>
>
>
> --
> --
> *José Miguel Faria*
> *Educed *- Engineering made better
> t: +351 913000266
> w: www.educed-emb.com
> e: jmf_at_xxxxxx >
> _______________________________________________
> The System Safety Mailing List
> systemsafety_at_xxxxxx > Klaus <klaus_sievers_at_xxxxxx > 18 November 2015 at 10:13 via Postbox
> <https://www.postbox-inc.com/?utm_source=email&utm_medium=sumlink&utm_campaign=reach>
> Well, hm...
> I fly 747 since 1987. Copilot, Captain...
> Distractions have increased, procedure design hasn´t quite
> kept up with all the things going on during the last minutes
> before departure.
>
> 20 years back, the data for takeoff were calculated by hand,
> using tables, and everything was ready 15, 20 minutes before
> pushback.
>
> Today, preliminary calculations are done 15, 20 minutes
> before pushback, but then updated with the latest info of
> + or - 5 passengers, a bit of cargo - whatever. THEN, with
> sheduled time of departure coming near, then things are
> recalculated and finally transferred, manually, into the airplane
> computers .
>
> Distractions ? You better be immune to them - which no-one
> can really be.
>
> About the 737: looks like a 10 ton error to me, maybe 15 % of
> takeoff-weight. May have been contributing, but I have doubts
> it was the main reason for the tail-strike.
>
> 747s , which are much larger than 737, have been known to
> scrape the runway, yes, but then the error was more than 25%
> of takeoff weight. 2xx tons instead of 3xx tons....
>
> Solution: try to keep a calm working athmosphere in the cockpit
> and do as much preparation as can be done : every moment counts.
> And: do the checklists, the required crosschecks.
>
> Hope that this was interesting,
>
> Best,
> Klaus Sievers
>
>
>
> _______________________________________________
> The System Safety Mailing List
> systemsafety_at_xxxxxx >
>
> _______________________________________________
> The System Safety Mailing List
> systemsafety_at_xxxxxx > <systemsafety_at_xxxxxx >
>

-- 
*Matthew Squair*
BEng (Mech) MSysEng
MIEAust CPEng

Mob: +61 488770655
Email: MattSquair_at_xxxxxx
Website: www.criticaluncertainties.com <http://criticaluncertainties.com/>



_______________________________________________ The System Safety Mailing List systemsafety_at_xxxxxx
Received on Sat Nov 21 2015 - 08:54:57 CET

This archive was generated by hypermail 2.3.0 : Sat Feb 16 2019 - 18:17:07 CET