Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch.embedded > #26509 > unrolled thread

QF72 story - wow

Back to article view | Back to comp.arch.embedded

Contents

  QF72 story - wow Clifford Heath <clifford.heath@gmail.com> - 2017-05-14 22:03 +1000
    Re: QF72 story - wow BM2335 <BM265@DMM.com.au> - 2017-05-15 12:25 +0800
    Re: QF72 story - wow Dimiter_Popoff <dp@tgi-sci.com> - 2017-05-15 16:05 +0300
      Re: QF72 story - wow Reinhardt Behm <rbehm@hushmail.com> - 2017-05-15 21:58 +0800
        Re: QF72 story - wow David Brown <david.brown@hesbynett.no> - 2017-05-15 16:48 +0200
          Re: QF72 story - wow Reinhardt Behm <rbehm@hushmail.com> - 2017-05-15 23:34 +0800
            Re: QF72 story - wow Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-05-15 18:00 +0100
            Re: QF72 story - wow Robert Wessel <robertwessel2@yahoo.com> - 2017-05-15 17:49 -0500
            Re: QF72 story - wow David Brown <david.brown@hesbynett.no> - 2017-05-16 09:06 +0200
              Re: QF72 story - wow upsidedown@downunder.com - 2017-05-16 19:46 +0300
            Re: QF72 story - wow rickman <gnuarm@gmail.com> - 2017-05-16 10:41 -0400
              Re: QF72 story - wow Reinhardt Behm <rbehm@hushmail.com> - 2017-05-17 23:13 +0800
                Re: QF72 story - wow rickman <gnuarm@gmail.com> - 2017-05-17 11:54 -0400
                  Re: QF72 story - wow Dimiter_Popoff <dp@tgi-sci.com> - 2017-05-17 21:43 +0300
                    Re: QF72 story - wow rickman <gnuarm@gmail.com> - 2017-05-17 16:03 -0400
                      Re: QF72 story - wow Dimiter_Popoff <dp@tgi-sci.com> - 2017-05-18 00:27 +0300
                        Re: QF72 story - wow rickman <gnuarm@gmail.com> - 2017-05-17 19:56 -0400
            Re: QF72 story - wow upsidedown@downunder.com - 2017-05-16 19:30 +0300
              Re: QF72 story - wow Robert Wessel <robertwessel2@yahoo.com> - 2017-05-16 23:05 -0500
              Re: QF72 story - wow Reinhardt Behm <rbehm@hushmail.com> - 2017-05-17 23:05 +0800
          Re: QF72 story - wow rickman <gnuarm@gmail.com> - 2017-05-16 10:25 -0400
        Re: QF72 story - wow Przemek Klosowski <przemek@tux.dot.org> - 2017-05-18 12:45 +0000
      Re: QF72 story - wow upsidedown@downunder.com - 2017-05-16 19:10 +0300
        Re: QF72 story - wow Dimiter_Popoff <dp@tgi-sci.com> - 2017-05-16 19:48 +0300
        Re: QF72 story - wow lasselangwadtchristensen@gmail.com - 2017-05-19 17:40 -0700
    Re: QF72 story - wow Tim Wescott <seemywebsite@myfooter.really> - 2017-05-15 12:34 -0500
      Re: QF72 story - wow Robert Wessel <robertwessel2@yahoo.com> - 2017-05-15 17:21 -0500
      Re: QF72 story - wow rickman <gnuarm@gmail.com> - 2017-05-16 10:47 -0400
        Re: QF72 story - wow Jan Coombs <jenfhaomndgfwutc@murmic.plus.com> - 2017-05-17 10:31 +0100
          Re: QF72 story - wow Reinhardt Behm <rbehm@hushmail.com> - 2017-05-17 22:20 +0800
            Re: QF72 story - wow rickman <gnuarm@gmail.com> - 2017-05-17 10:36 -0400
    Re: QF72 story - wow George Neuner <gneuner2@comcast.net> - 2017-05-15 17:28 -0400
      Re: QF72 story - wow Robert Wessel <robertwessel2@yahoo.com> - 2017-05-15 17:22 -0500
      Re: QF72 story - wow Dimiter_Popoff <dp@tgi-sci.com> - 2017-05-16 10:51 +0300
        Re: QF72 story - wow Clifford Heath <clifford.heath@gmail.com> - 2017-05-16 18:01 +1000
    Re: QF72 story - wow upsidedown@downunder.com - 2017-05-16 18:54 +0300
      Re: QF72 story - wow Robert Wessel <robertwessel2@yahoo.com> - 2017-05-16 23:23 -0500

Page 1 of 2  [1] 2  Next page →

#26509 — QF72 story - wow

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>

[toc] | [next] | [standalone]

#26512

On 14-May-17 8:03 PM, 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> 
> 
Yep, it was an interesting read for sure.

[toc] | [prev] | [next] | [standalone]

#26513

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".

But I certainly seem to know why I don't fly unless I really
have to. Europe is small enough to travel by car, train or bus
(have done all of these, rarely of course so it has been practical).
Last time I flew was during the Soviet era, this was my only way
to "defect" to West Germany back then. It was a Tu-134 IIRC, which
must have had mechanical controls and all but I remember how every
new sound (there was a ventilator or something which got on 
periodically) almost turned me into a religious person... well,
at least while the flight lasted :).

Dimiter

------------------------------------------------------
Dimiter Popoff, TGI             http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/

[toc] | [prev] | [next] | [standalone]

#26514

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.
 
Similar to the crash of an Airbus in Warsaw. In that case it was an 
interlock that prevented the thrust reversal when not both wheels see 
weight-on-wheel. The landing happened with extreme side wind keeping one 
side slightly lifted. Thus thrust reversal was blocked and the plane ran 
past the runway and crashed into the ground, killing most passengers. 
This interlock had been implemented after a Lauda Air crashed in south east 
Asia because the thrust reversal was activated in mid air.
This is why you normally have reviews of system requirements and for every 
change you have to perform an impact analysis to prevent such oversights.

-- 
Reinhardt

[toc] | [prev] | [next] | [standalone]

#26515

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?


> Similar to the crash of an Airbus in Warsaw. In that case it was an 
> interlock that prevented the thrust reversal when not both wheels see 
> weight-on-wheel. The landing happened with extreme side wind keeping one 
> side slightly lifted. Thus thrust reversal was blocked and the plane ran 
> past the runway and crashed into the ground, killing most passengers. 
> This interlock had been implemented after a Lauda Air crashed in south east 
> Asia because the thrust reversal was activated in mid air.
> This is why you normally have reviews of system requirements and for every 
> change you have to perform an impact analysis to prevent such oversights.
> 

[toc] | [prev] | [next] | [standalone]

#26516

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.
 
> 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.

-- 
Reinhardt

[toc] | [prev] | [next] | [standalone]

#26519

On 15/05/17 16:34, Reinhardt Behm wrote:
> Most problems  are really in the sys-reqs.

It will be interesting to see whether the
sys-reqs for self-driving cars will
require/forbid/ignore/punt whether the control
system should kill the  driver to save N
pedestrians.

I suspect that, as they say, is an area
of active research.

[toc] | [prev] | [next] | [standalone]

#26525

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.

[toc] | [prev] | [next] | [standalone]

#26526

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.
> 

[toc] | [prev] | [next] | [standalone]

#26535

On Tue, 16 May 2017 09:06:40 +0200, David Brown
<david.brown@hesbynett.no> wrote:

>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.

Not only that, you need sensors with different working principles
after 2-3 normal redundant sensors.

>And multiple people writing specifications independently, before they
>are combined (and then checked by multiple people).

That helps. 

>I fully agree with you - it is often the specifications and system
>requirements that are the issue.

That is one issue as is getting _reliable_ sensor data.

[toc] | [prev] | [next] | [standalone]

#26530

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

[toc] | [prev] | [next] | [standalone]

#26583

AT Tuesday 16 May 2017 22:41, rickman wrote:

> 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.

You are right. I meant the landing on the Hudson. I should not post just 
before midnight from memory alone.
> 
> 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?

When sitting in that plane over NYC my preferences would be clear. Against 
all  statistics.
> 
> 
>>> 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!

I am concerned about it having some projects in nuclear plants I know how 
thoughtlessly people act there not even caring about defined procedures. The 
plants were not in Russia or some such, but in Germany. Some of the 
incidents never got reported. I am glad Germany is shutting down that stuff.
 
-- 
Reinhardt

[toc] | [prev] | [next] | [standalone]

#26586

On 5/17/2017 11:13 AM, Reinhardt Behm wrote:
> AT Tuesday 16 May 2017 22:41, rickman wrote:
>
>> 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.
>
> You are right. I meant the landing on the Hudson. I should not post just
> before midnight from memory alone.
>>
>> 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?
>
> When sitting in that plane over NYC my preferences would be clear. Against
> all  statistics.

This is such a perfect example of emotion ruling over logic.  Thank you.


>>>> 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!
>
> I am concerned about it having some projects in nuclear plants I know how
> thoughtlessly people act there not even caring about defined procedures. The
> plants were not in Russia or some such, but in Germany. Some of the
> incidents never got reported. I am glad Germany is shutting down that stuff.

The problems with the nuclear industry that were revealed by the 
incident at the North Anna plant run deep.  Did you know Dominion Power 
*lied* on their application for the North Anna reactors, not reporting 
the known existence of a nearby fault?  They were caught and fined a 
mere $30,000 dollars.

-- 

Rick C

[toc] | [prev] | [next] | [standalone]

#26605

On 17.5.2017 г. 18:54, rickman wrote:
> On 5/17/2017 11:13 AM, Reinhardt Behm wrote:
> ......
>>> 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?
>>
>> When sitting in that plane over NYC my preferences would be clear.
>> Against
>> all  statistics.
>
> This is such a perfect example of emotion ruling over logic.  Thank you.

No it is not. Just the statistics are based on incomplete or invalid
data.

Here is an example why. Fewer people die in plain crashes per
person*distance than in car crashes, this is known.
However the percentage of idiots among pilots is a lot lower than
among drivers; I am sure the results will be different if the same
comparison is made say for planes vs. buses on reputable bus lines.

Then there are nowhere near enough data to make the stats on human
pilots vs. autopilots on similar enough planes, it will all be below
the noise floor.

Completely automated planes are a good idea a target which must be
pursued but humanity is not there yet, not by a long stretch.
Then given how *messy* todays software is I don't see it done any
time soon.

I know I would want to have access to all the controls - debugging 
included... - if I flew an autopiloted plane *I* have programmmed - and
my software is anything but messy.

Dimiter

------------------------------------------------------
Dimiter Popoff, TGI             http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/

[toc] | [prev] | [next] | [standalone]

#26609

On 5/17/2017 2:43 PM, Dimiter_Popoff wrote:
> On 17.5.2017 г. 18:54, rickman wrote:
>> On 5/17/2017 11:13 AM, Reinhardt Behm wrote:
>> ......
>>>> 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?
>>>
>>> When sitting in that plane over NYC my preferences would be clear.
>>> Against
>>> all  statistics.
>>
>> This is such a perfect example of emotion ruling over logic.  Thank you.
>
> No it is not. Just the statistics are based on incomplete or invalid
> data.
>
> Here is an example why. Fewer people die in plain crashes per
> person*distance than in car crashes, this is known.
> However the percentage of idiots among pilots is a lot lower than
> among drivers; I am sure the results will be different if the same
> comparison is made say for planes vs. buses on reputable bus lines.

You are mixing issues.  If you compare cars vs. airplane, that is cars 
vs. airplanes.  What do busses have to do with anything?


> Then there are nowhere near enough data to make the stats on human
> pilots vs. autopilots on similar enough planes, it will all be below
> the noise floor.

And yet the data is there and it is clear.


> Completely automated planes are a good idea a target which must be
> pursued but humanity is not there yet, not by a long stretch.
> Then given how *messy* todays software is I don't see it done any
> time soon.

We don't know the future.  But again, you are discussing your emotions, 
not the facts.


> I know I would want to have access to all the controls - debugging
> included... - if I flew an autopiloted plane *I* have programmmed - and
> my software is anything but messy.

If you have no confidence in your code, I certainly don't.  I'm  staying 
off of Popoff airlines.

-- 

Rick C

[toc] | [prev] | [next] | [standalone]

#26610

On 17.5.2017 г. 23:03, rickman wrote:
> On 5/17/2017 2:43 PM, Dimiter_Popoff wrote:
>> On 17.5.2017 г. 18:54, rickman wrote:
>>> On 5/17/2017 11:13 AM, Reinhardt Behm wrote:
>>> ......
>>>>> 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?
>>>>
>>>> When sitting in that plane over NYC my preferences would be clear.
>>>> Against
>>>> all  statistics.
>>>
>>> This is such a perfect example of emotion ruling over logic.  Thank you.
>>
>> No it is not. Just the statistics are based on incomplete or invalid
>> data.
>>
>> Here is an example why. Fewer people die in plain crashes per
>> person*distance than in car crashes, this is known.
>> However the percentage of idiots among pilots is a lot lower than
>> among drivers; I am sure the results will be different if the same
>> comparison is made say for planes vs. buses on reputable bus lines.
>
> You are mixing issues.  If you compare cars vs. airplane, that is cars
> vs. airplanes.  What do busses have to do with anything?

I am sure you see the point, you just choose denial.

>
>> Then there are nowhere near enough data to make the stats on human
>> pilots vs. autopilots on similar enough planes, it will all be below
>> the noise floor.
>
> And yet the data is there and it is clear.

No it is not.

>
>
>> Completely automated planes are a good idea a target which must be
>> pursued but humanity is not there yet, not by a long stretch.
>> Then given how *messy* todays software is I don't see it done any
>> time soon.
>
> We don't know the future.  But again, you are discussing your emotions,
> not the facts.

Not at all, where did you see any emotion in that.

>
>
>> I know I would want to have access to all the controls - debugging
>> included... - if I flew an autopiloted plane *I* have programmmed - and
>> my software is anything but messy.
>
> If you have no confidence in your code, I certainly don't.  I'm  staying
> off of Popoff airlines.

You are trying to be smart because you understand you are wrong now, OK.
I am sure to understand my point well enough - which is that I would
choose to have control even over my software which I deem safer than
anyone elses.

Dimiter

------------------------------------------------------
Dimiter Popoff, TGI             http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/

[toc] | [prev] | [next] | [standalone]

#26611

On 5/17/2017 5:27 PM, Dimiter_Popoff wrote:
> On 17.5.2017 г. 23:03, rickman wrote:
>> On 5/17/2017 2:43 PM, Dimiter_Popoff wrote:
>>> On 17.5.2017 г. 18:54, rickman wrote:
>>>> On 5/17/2017 11:13 AM, Reinhardt Behm wrote:
>>>> ......
>>>>>> 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?
>>>>>
>>>>> When sitting in that plane over NYC my preferences would be clear.
>>>>> Against
>>>>> all  statistics.
>>>>
>>>> This is such a perfect example of emotion ruling over logic.  Thank
>>>> you.
>>>
>>> No it is not. Just the statistics are based on incomplete or invalid
>>> data.
>>>
>>> Here is an example why. Fewer people die in plain crashes per
>>> person*distance than in car crashes, this is known.
>>> However the percentage of idiots among pilots is a lot lower than
>>> among drivers; I am sure the results will be different if the same
>>> comparison is made say for planes vs. buses on reputable bus lines.
>>
>> You are mixing issues.  If you compare cars vs. airplane, that is cars
>> vs. airplanes.  What do busses have to do with anything?
>
> I am sure you see the point, you just choose denial.
>
>>
>>> Then there are nowhere near enough data to make the stats on human
>>> pilots vs. autopilots on similar enough planes, it will all be below
>>> the noise floor.
>>
>> And yet the data is there and it is clear.
>
> No it is not.
>
>>
>>
>>> Completely automated planes are a good idea a target which must be
>>> pursued but humanity is not there yet, not by a long stretch.
>>> Then given how *messy* todays software is I don't see it done any
>>> time soon.
>>
>> We don't know the future.  But again, you are discussing your emotions,
>> not the facts.
>
> Not at all, where did you see any emotion in that.
>
>>
>>
>>> I know I would want to have access to all the controls - debugging
>>> included... - if I flew an autopiloted plane *I* have programmmed - and
>>> my software is anything but messy.
>>
>> If you have no confidence in your code, I certainly don't.  I'm  staying
>> off of Popoff airlines.
>
> You are trying to be smart because you understand you are wrong now, OK.
> I am sure to understand my point well enough - which is that I would
> choose to have control even over my software which I deem safer than
> anyone elses.

If you don't want to discuss the issue, why did you reply?

-- 

Rick C

[toc] | [prev] | [next] | [standalone]

#26534

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.
> 
>> 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.


As far as I understand, they used Ariane-4 flight control software,
which caused an integer overflow on Ariane-5 due to more dynamic
movement. 

I was happy that our satellite was not on the first launch of Ariane-5
as originally planned :-).

[toc] | [prev] | [next] | [standalone]

#26559

On Tue, 16 May 2017 19:30:38 +0300, upsidedown@downunder.com wrote:

>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.
>> 
>>> 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.
>
>
>As far as I understand, they used Ariane-4 flight control software,
>which caused an integer overflow on Ariane-5 due to more dynamic
>movement. 


Well, they adapted the Ariane-4 software (working code, and all that).
What makes this failure especially annoying is that the -5 no longer
actually needed the result of the calculation that triggered the
overflow.

[toc] | [prev] | [next] | [standalone]

#26581

AT Wednesday 17 May 2017 00:30, upsidedown@downunder.com wrote:

> 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.
>> 
>>> 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.
> 
> 
> As far as I understand, they used Ariane-4 flight control software,
> which caused an integer overflow on Ariane-5 due to more dynamic
> movement.
> 
> I was happy that our satellite was not on the first launch of Ariane-5
> as originally planned :-).

Correct. But somebody should have checked the specs for this old module if 
it fits into he new environment.

-- 
Reinhardt

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.arch.embedded

csiph-web