On Mon, 15 May 2017 17:28:36 -0400, George Neuner <gneuner2@comcast.net> wrote:>On Sun, 14 May 2017 22:03:19 +1000, Clifford Heath ><clifford.heath@gmail.com> wrote: > >>This story is a doozy. >><http://www.smh.com.au/good-weekend/the-untold-story-of-qf72-what-happens-when-psycho-automation-leaves-pilots-powerless-20170510-gw26ae.html> > > >Instead of a newspaper, why not read the accident report? > >https://www.atsb.gov.au/publications/investigation_reports/2008/aair/ao-2008-070.aspxYou beat me to it. Unlike the breathless article, it actually has useful, and factual, information. It's not that hard a read, either.
QF72 story - wow
Started by ●May 14, 2017
Reply by ●May 15, 20172017-05-15
Reply by ●May 15, 20172017-05-15
On Mon, 15 May 2017 23:34:21 +0800, Reinhardt Behm <rbehm@hushmail.com> wrote:>AT Monday 15 May 2017 22:48, David Brown wrote: > >> On 15/05/17 15:58, Reinhardt Behm wrote: >>> AT Monday 15 May 2017 21:05, Dimiter_Popoff wrote: >>> >>>> On 14.5.2017 ?. 15:03, Clifford Heath wrote: >>>>> This story is a doozy. >>>>> <http://www.smh.com.au/good-weekend/the-untold-story-of-qf72-what- >>> happens-when-psycho-automation-leaves-pilots-powerless-20170510- >gw26ae.html> >>>>> >>>> >>>> Interesting reading, I read almost the whole article. If I start >>>> commenting on the quality of the software they mut have on these planes >>>> I'll go into a rant predictable to all seasoned group members so >>>> I won't. >>>> >>>> But I am amazed that - as the article states - the board computer >>>> on these planes has priority over the pilots. This is not a bug, it >>>> is an error at the product concept level... If it is true of course, >>>> I still have difficulties believing that. The fact they did manage >>>> to gain some manual control hints towards "not quite true". >>> >>> I am doing airborne software myself. >>> You are correct. It is not a bug, it is a serious error of the >>> requirements. Software has to be written according to requirements and >>> this is verified (DO-178). If the sys-reqs are erroneous the software is >>> also incorrect. >>> >> >> What about that case of a plane crash because the pilot intentionally >> crashed it (as far as they could figure out afterwards, anyway)? He was >> mentally unstable and drove the plane into a mountain. If the onboard >> computers had had priority over the pilot in that case, there would have >> been no crash. >> >> It is far from easy to say who or what is most reliable in cases like >> this, and who or what should have priority. Automated systems can (if >> designed properly) be safer and more stable than humans - but on the >> other hand, humans are better at handling unexpected situations. > >That was shown with the landing on the Potomac. > >That is a decision nobody can really make. > >But some systems designers think their computers can be better. That makes >me afraid of self driving cars. I am not sure if there are really good >software development procedures in place. All that "self-learning" stuff and >we have "big-data" so we do not have to understand it is irresponsible to >me.FWIW, so far the autonomous cars have racked up an impressively low accident rate compared to the human driven cars they're sharing the road with. Perfection is not a requirement. Better than 95% of the idiots on the road would be a massive improvement in safety.>> However, I thought that critical flight systems were made in triplicate, >> and if one goes bananas it gets outvoted, and the other two run the >> plane? Did that not happen here? > >Well even if there were multiple system they behaved according to their >common specifications. If these are incorrect, all systems behave correctly >incorrect. > >Most problems are really in the sys-reqs. The software development >processes in DO-78 are good and try to guaranty software that comply with >the sys-reqs. >Also the most famous crash (Ariane-5) was not due to buggy software but >happened because the requirements for the module that lead to the crash were >not correctly reviewed - the original reqs were not fit for the new >environment. > >From the report about the Quantas flight it seems to me that nobody did >think about what should happen if the sensors report invalid data or signal >errors.Of course they did. The resulting fault was intermittent, and at intervals almost designed to fool the algorithms designed to filter our glitchy data. Obviously that's still an oversight, but it's far from "nobody did think about what should happen if the sensors report invalid data or signal errors".>The Air France from Brazil to Europe that crashed over the Atlantic comes to >mind. There the pitot tubes gave bad data because of icing. Seems they have >not learned from it.No pitot tube ever built can withstand the worst case icing possible. It's likely that the older pitot probes were a bit more susceptible to icing than the newer ones they were scheduled to be replaced with, although that was not prime reason for the scheduled replacement. In the case of AF447 the computers punted back to the pilots when the data became unreliable. The pilots failed to follow the correct procedures (fly pitch and power), that's the same for any airliner that's lost its airspeed indication in cruise. The resulting stall was only possible because many of the hard protections had been disabled by the bad data. The pitots cleared in a few 10s of seconds (they have rather big heaters attached, and worst case icing tends to be fairly brief), and the crew spent the rest of the flight in a perfectly functional airplane, watching the ocean rise up to smack them. There were design issues that probably contributed to the crews utter lack of understanding, most notably the intermittent and counterintuitive behavior of the stall warning (the stall warning was disabled at less the 60kts, and given the ~40 degree angle of attack, the pitots were actually seeing less than that, so the stall warning would come *on* when they started to pitch down). Still, a 10,000ft/min descent at less than 100kts airspeed (and ~100kts ground speed), with a normal-ish/high deck angle, and the engines at full howl can't be anything but a stall.
Reply by ●May 16, 20172017-05-16
On 15/05/17 17:34, Reinhardt Behm wrote:> AT Monday 15 May 2017 22:48, David Brown wrote: > >> On 15/05/17 15:58, Reinhardt Behm wrote: >>> AT Monday 15 May 2017 21:05, Dimiter_Popoff wrote: >>> >>>> On 14.5.2017 г. 15:03, Clifford Heath wrote: >>>>> This story is a doozy. >>>>> <http://www.smh.com.au/good-weekend/the-untold-story-of-qf72-what- >>> happens-when-psycho-automation-leaves-pilots-powerless-20170510- > gw26ae.html> >>>>> >>>> >>>> Interesting reading, I read almost the whole article. If I start >>>> commenting on the quality of the software they mut have on these planes >>>> I'll go into a rant predictable to all seasoned group members so >>>> I won't. >>>> >>>> But I am amazed that - as the article states - the board computer >>>> on these planes has priority over the pilots. This is not a bug, it >>>> is an error at the product concept level... If it is true of course, >>>> I still have difficulties believing that. The fact they did manage >>>> to gain some manual control hints towards "not quite true". >>> >>> I am doing airborne software myself. >>> You are correct. It is not a bug, it is a serious error of the >>> requirements. Software has to be written according to requirements and >>> this is verified (DO-178). If the sys-reqs are erroneous the software is >>> also incorrect. >>> >> >> What about that case of a plane crash because the pilot intentionally >> crashed it (as far as they could figure out afterwards, anyway)? He was >> mentally unstable and drove the plane into a mountain. If the onboard >> computers had had priority over the pilot in that case, there would have >> been no crash. >> >> It is far from easy to say who or what is most reliable in cases like >> this, and who or what should have priority. Automated systems can (if >> designed properly) be safer and more stable than humans - but on the >> other hand, humans are better at handling unexpected situations. > > That was shown with the landing on the Potomac. > > That is a decision nobody can really make. > > But some systems designers think their computers can be better. That makes > me afraid of self driving cars. I am not sure if there are really good > software development procedures in place. All that "self-learning" stuff and > we have "big-data" so we do not have to understand it is irresponsible to > me.At least with self-driving cars, if the systems detect a problem they can stop the car at the side of the road and call the AA. That is not so easy in a plane!> >> However, I thought that critical flight systems were made in triplicate, >> and if one goes bananas it gets outvoted, and the other two run the >> plane? Did that not happen here? > > Well even if there were multiple system they behaved according to their > common specifications. If these are incorrect, all systems behave correctly > incorrect.So you need multiple sensors too. And multiple people writing specifications independently, before they are combined (and then checked by multiple people). I fully agree with you - it is often the specifications and system requirements that are the issue.> > Most problems are really in the sys-reqs. The software development > processes in DO-78 are good and try to guaranty software that comply with > the sys-reqs. > Also the most famous crash (Ariane-5) was not due to buggy software but > happened because the requirements for the module that lead to the crash were > not correctly reviewed - the original reqs were not fit for the new > environment. > > From the report about the Quantas flight it seems to me that nobody did > think about what should happen if the sensors report invalid data or signal > errors. > The Air France from Brazil to Europe that crashed over the Atlantic comes to > mind. There the pitot tubes gave bad data because of icing. Seems they have > not learned from it. >
Reply by ●May 16, 20172017-05-16
On 16.5.2017 г. 00:28, George Neuner wrote:> On Sun, 14 May 2017 22:03:19 +1000, Clifford Heath > <clifford.heath@gmail.com> wrote: > >> This story is a doozy. >> <http://www.smh.com.au/good-weekend/the-untold-story-of-qf72-what-happens-when-psycho-automation-leaves-pilots-powerless-20170510-gw26ae.html> > > > Instead of a newspaper, why not read the accident report? > > https://www.atsb.gov.au/publications/investigation_reports/2008/aair/ao-2008-070.aspx >Hmmmm, sounds a little like a whitewash. "Happened just once" in so many millions flight hours etc. - we all here know what this means. This clearly is a programming error - and not one which is to be caught by testing, rather the programmer must be good enough to not allow it happen by design, during planning. On the "automata are better than humans" from other posts - if they are better and humans cannot override them why are there any humans at all in the cockpit? I know if I were to fly something I would want to be in control when I want to be, although of course I would make use of all utilities available as long as they work OK. Dimiter ------------------------------------------------------ Dimiter Popoff, TGI http://www.tgi-sci.com ------------------------------------------------------ http://www.flickr.com/photos/didi_tgi/
Reply by ●May 16, 20172017-05-16
On 16/05/17 17:51, Dimiter_Popoff wrote:> On 16.5.2017 г. 00:28, George Neuner wrote: >> On Sun, 14 May 2017 22:03:19 +1000, Clifford Heath >> <clifford.heath@gmail.com> wrote: >> >>> This story is a doozy. >>> <http://www.smh.com.au/good-weekend/the-untold-story-of-qf72-what-happens-when-psycho-automation-leaves-pilots-powerless-20170510-gw26ae.html> >>> >> >> >> Instead of a newspaper, why not read the accident report? >> https://www.atsb.gov.au/publications/investigation_reports/2008/aair/ao-2008-070.aspxThanks, that was interesting.> Hmmmm, sounds a little like a whitewash. "Happened just once" in so many > millions flight hours etc. - we all here know what this means. > This clearly is a programming error - and not one which is to be caught > by testing, rather the programmer must be good enough to not allow it > happen by design, during planning. > > On the "automata are better than humans" from other posts - if they are > better and humans cannot override them why are there any humans at all > in the cockpit? I know if I were to fly something I would want to be > in control when I want to be, although of course I would make use of > all utilities available as long as they work OK.The accident report suggests that the sensor computer attributed the right value to the wrong sensor. That seems very likely to not be a cosmic ray strike... but it could be a static pointer to a data structure that isn't meant to change, and one bit got flipped. Such things shouldn't happen in this class of software, of course. Clifford Heath
Reply by ●May 16, 20172017-05-16
On 5/15/2017 10:48 AM, David Brown wrote:> On 15/05/17 15:58, Reinhardt Behm wrote: >> AT Monday 15 May 2017 21:05, Dimiter_Popoff wrote: >> >>> On 14.5.2017 г. 15:03, Clifford Heath wrote: >>>> This story is a doozy. >>>> <http://www.smh.com.au/good-weekend/the-untold-story-of-qf72-what- >> happens-when-psycho-automation-leaves-pilots-powerless-20170510-gw26ae.html> >>>> >>> >>> Interesting reading, I read almost the whole article. If I start >>> commenting on the quality of the software they mut have on these planes >>> I'll go into a rant predictable to all seasoned group members so >>> I won't. >>> >>> But I am amazed that - as the article states - the board computer >>> on these planes has priority over the pilots. This is not a bug, it >>> is an error at the product concept level... If it is true of course, >>> I still have difficulties believing that. The fact they did manage >>> to gain some manual control hints towards "not quite true". >> >> I am doing airborne software myself. >> You are correct. It is not a bug, it is a serious error of the requirements. >> Software has to be written according to requirements and this is verified >> (DO-178). If the sys-reqs are erroneous the software is also incorrect. >> > > What about that case of a plane crash because the pilot intentionally > crashed it (as far as they could figure out afterwards, anyway)? He was > mentally unstable and drove the plane into a mountain. If the onboard > computers had had priority over the pilot in that case, there would have > been no crash. > > It is far from easy to say who or what is most reliable in cases like > this, and who or what should have priority. Automated systems can (if > designed properly) be safer and more stable than humans - but on the > other hand, humans are better at handling unexpected situations. > > However, I thought that critical flight systems were made in triplicate, > and if one goes bananas it gets outvoted, and the other two run the > plane? Did that not happen here?Didn't anyone pay attention? There were a total of 10 errors that happened to cause the misreporting of the angle of the airplane. These errors were not reported to the pilots. This was the failure of the system, not the fact that the plane overrode the pilot's commands. The statistics don't lie. Most accidents are caused by pilot errors, not plane malfunctions. That is why the plane can override the pilot. Humans are almost always the weak link in the system. In this case the errors should have been reported to the pilots so they could take action to prevent the misreporting of critical flight information. The malfunctioning systems could have been shut down, not unlike HAL in 2001, but without the drama. -- Rick C
Reply by ●May 16, 20172017-05-16
On 5/15/2017 11:34 AM, Reinhardt Behm wrote:> AT Monday 15 May 2017 22:48, David Brown wrote: > >> On 15/05/17 15:58, Reinhardt Behm wrote: >>> AT Monday 15 May 2017 21:05, Dimiter_Popoff wrote: >>> >>>> On 14.5.2017 г. 15:03, Clifford Heath wrote: >>>>> This story is a doozy. >>>>> <http://www.smh.com.au/good-weekend/the-untold-story-of-qf72-what- >>> happens-when-psycho-automation-leaves-pilots-powerless-20170510- > gw26ae.html> >>>>> >>>> >>>> Interesting reading, I read almost the whole article. If I start >>>> commenting on the quality of the software they mut have on these planes >>>> I'll go into a rant predictable to all seasoned group members so >>>> I won't. >>>> >>>> But I am amazed that - as the article states - the board computer >>>> on these planes has priority over the pilots. This is not a bug, it >>>> is an error at the product concept level... If it is true of course, >>>> I still have difficulties believing that. The fact they did manage >>>> to gain some manual control hints towards "not quite true". >>> >>> I am doing airborne software myself. >>> You are correct. It is not a bug, it is a serious error of the >>> requirements. Software has to be written according to requirements and >>> this is verified (DO-178). If the sys-reqs are erroneous the software is >>> also incorrect. >>> >> >> What about that case of a plane crash because the pilot intentionally >> crashed it (as far as they could figure out afterwards, anyway)? He was >> mentally unstable and drove the plane into a mountain. If the onboard >> computers had had priority over the pilot in that case, there would have >> been no crash. >> >> It is far from easy to say who or what is most reliable in cases like >> this, and who or what should have priority. Automated systems can (if >> designed properly) be safer and more stable than humans - but on the >> other hand, humans are better at handling unexpected situations. > > That was shown with the landing on the Potomac.I'm not sure if this is a joke. I believe you are thinking of the "landing on the Hudson" in NY where everyone lived. The landing on the Potomac was Air Florida flight 90 where only four or five lived after the plane struck the 14th street bridge (also killing some drivers) in January, plunging everyone into icy waters. There were multiple causes of this accident and most of them were pilot errors showing how poor humans are and keeping us safe.> That is a decision nobody can really make.???> But some systems designers think their computers can be better. That makes > me afraid of self driving cars. I am not sure if there are really good > software development procedures in place. All that "self-learning" stuff and > we have "big-data" so we do not have to understand it is irresponsible to > me.Don't worry about the details, consider the statistics. Computers only need to be better than people and so far they have been for driving cars. If you have 1 in 1E6 chance of dying with a human pilot and a 1 in 1E7 chance of dying with a computer pilot, which will you choose?>> However, I thought that critical flight systems were made in triplicate, >> and if one goes bananas it gets outvoted, and the other two run the >> plane? Did that not happen here? > > Well even if there were multiple system they behaved according to their > common specifications. If these are incorrect, all systems behave correctly > incorrect. > > Most problems are really in the sys-reqs. The software development > processes in DO-78 are good and try to guaranty software that comply with > the sys-reqs. > Also the most famous crash (Ariane-5) was not due to buggy software but > happened because the requirements for the module that lead to the crash were > not correctly reviewed - the original reqs were not fit for the new > environment. > > From the report about the Quantas flight it seems to me that nobody did > think about what should happen if the sensors report invalid data or signal > errors. > The Air France from Brazil to Europe that crashed over the Atlantic comes to > mind. There the pitot tubes gave bad data because of icing. Seems they have > not learned from it.These issues are not really "computer" issues, they are systems design issues. I find it funny that people get so excited about systems flying planes and driving cars, but no one thinks twice about systems running nuclear power plants. In the east coast earthquake a few years back the North Anna power plant was about 10 miles from the epicenter. The plant received twice the seismic impact it was designed for. The plant was taken offline and the generators were fired up. After a few minutes one generator failed. A subsequent analysis found the cause was faulty installation of a head gasket which in turn was caused by an incorrect installation procedure, an installation procedure that was common to *all* the generators! This was a single point of failure that could have resulted in a core meltdown as a result of a bad system design. Why are people so unconcerned with nuclear power? Because we have not had enough accidents in the US... yet! -- Rick C
Reply by ●May 16, 20172017-05-16
On 5/15/2017 1:34 PM, Tim Wescott wrote:> On Sun, 14 May 2017 22:03:19 +1000, Clifford Heath wrote: > >> This story is a doozy. >> <http://www.smh.com.au/good-weekend/the-untold-story-of-qf72-what- > happens-when-psycho-automation-leaves-pilots-powerless-20170510- > gw26ae.html> > > Airbus has always had a policy of believing that engineers can program a > blind computer to fly a plane better than a pilot with eyeballs.Which is true! Pilot error is the single biggest cause of fatalities in plane accidents.> In > addition to this event, it's resulted in planes flying into mountainsides > with wings that simply were not stressed with any excessive G-forces from > the requested pullup. > > I have friends who are Boeing engineers. Boeing's policy is that if > you're going to have a human pilot in the hot seat, you should trust him > when the chips are down. This makes for more impressive crashes when > less than well-trained pilots are flying the planes, but fewer crashes > when you've got good piloting.How do you decide when the chips are down? I'd like to see the statistics you are quoting. -- Rick C
Reply by ●May 16, 20172017-05-16
On Sun, 14 May 2017 22:03:19 +1000, Clifford Heath <clifford.heath@gmail.com> wrote:>This story is a doozy. ><http://www.smh.com.au/good-weekend/the-untold-story-of-qf72-what-happens-when-psycho-automation-leaves-pilots-powerless-20170510-gw26ae.html>A much better factual description can be found in Aviation Herald http://www.avherald.com/h?article=40de5374/0006&opt=0 Regarding the referenced Air France 447 crash into the Atlantic, which was nat caused by automation but by inexperienced co-pilots (captain was sleeping) who manually stalled the plane from 10 km to the sea due to frozen pitot tubes (and hence no reliable speed info). As a general observation, one should not rely on a single method of redundancy. Using multiple sensors of the same type doesn't always help. This was clearly shown in Fukushima, were all diesel emergency power generators got wet due to the tsunami.
Reply by ●May 16, 20172017-05-16
On Mon, 15 May 2017 16:05:11 +0300, Dimiter_Popoff <dp@tgi-sci.com> wrote:>On 14.5.2017 ?. 15:03, Clifford Heath wrote: >> This story is a doozy. >> <http://www.smh.com.au/good-weekend/the-untold-story-of-qf72-what-happens-when-psycho-automation-leaves-pilots-powerless-20170510-gw26ae.html> >> > >Interesting reading, I read almost the whole article. If I start >commenting on the quality of the software they mut have on these planes >I'll go into a rant predictable to all seasoned group members so >I won't. > >But I am amazed that - as the article states - the board computer >on these planes has priority over the pilots. This is not a bug, it >is an error at the product concept level... If it is true of course, >I still have difficulties believing that. The fact they did manage >to gain some manual control hints towards "not quite true".Look at the AF286 crash at Mulhouse when after a low fly-by the plane dropped into the trees at the hill at the end of the runway. The automation prevented a pilot too high nose up attitude, which would have caused a stall to the ground, causing a lot of fatalities. In this case, the pane dropped below the tree line softly with a small number of fatalities.
