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

Groups > comp.lang.c > #93534 > unrolled thread

Continue with learning C

Back to article view | Back to comp.lang.c

Contents

  Continue with learning C Alla _ <modelling.data@gmail.com> - 2016-09-15 05:11 -0700
    Re: Continue with learning C "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-09-15 05:29 -0700
    Re: Continue with learning C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-15 15:01 +0100
    Re: Continue with learning C Richard Heathfield <rjh@cpax.org.uk> - 2016-09-15 15:32 +0100
      Re: Continue with learning C Alla _ <modelling.data@gmail.com> - 2016-09-15 08:10 -0700
      Re: Continue with learning C luser droog <luser.droog@gmail.com> - 2016-09-15 12:06 -0700
        Re: Continue with learning C Richard Heathfield <rjh@cpax.org.uk> - 2016-09-15 21:38 +0100
          Re: Continue with learning C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-16 21:02 -0700
            Re: Continue with learning C "Osmium" <r124c4u102@comcast.net> - 2016-09-17 08:03 -0500
            Re: Continue with learning C Richard Heathfield <rjh@cpax.org.uk> - 2016-09-17 22:38 +0100
              Re: Continue with learning C "James R. Kuyper" <jameskuyper@verizon.net> - 2016-09-17 18:14 -0400
                Re: Continue with learning C raltbos@xs4all.nl (Richard Bos) - 2016-09-18 10:47 +0000
                Re: Continue with learning C Alla _ <modelling.data@gmail.com> - 2016-09-19 01:25 -0700
                  Re: Continue with learning C Ian Collins <ian-news@hotmail.com> - 2016-09-19 20:51 +1200
                  Re: Continue with learning C James Kuyper <jameskuyper@verizon.net> - 2016-09-19 09:49 -0400
                  Re: Continue with learning C Richard Heathfield <rjh@cpax.org.uk> - 2016-09-19 15:15 +0100
                  Re: Continue with learning C Keith Thompson <kst-u@mib.org> - 2016-09-19 11:39 -0700
                    Re: Continue with learning C Reinhardt Behm <rbehm@hushmail.com> - 2016-09-20 09:55 +0800
                      Re: Continue with learning C David Brown <david.brown@hesbynett.no> - 2016-09-20 08:50 +0200
                        Re: Continue with learning C Reinhardt Behm <rbehm@hushmail.com> - 2016-09-20 18:04 +0800
                          Re: Continue with learning C David Brown <david.brown@hesbynett.no> - 2016-09-20 13:25 +0200
                            Re: Continue with learning C Reinhardt Behm <rbehm@hushmail.com> - 2016-09-20 20:18 +0800
                              Re: Continue with learning C David Brown <david.brown@hesbynett.no> - 2016-09-20 15:25 +0200
                      Re: Continue with learning C Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-20 08:45 -0400
                        Re: Continue with learning C Reinhardt Behm <rbehm@hushmail.com> - 2016-09-20 22:05 +0800
                          Re: Continue with learning C Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-20 10:56 -0400
                  Re: Continue with learning C Rosario19 <Ros@invalid.invalid> - 2016-09-19 18:55 +0200
                  Re: Continue with learning C Anton Shepelev <anton.txt@gmail.com> - 2016-09-25 01:08 +0300
              Re: Continue with learning C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-17 17:08 -0700
                Re: Continue with learning C Richard Heathfield <rjh@cpax.org.uk> - 2016-09-18 01:11 +0100
                  Re: Continue with learning C Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-17 21:32 -0400
                    Re: Continue with learning C David Brown <david.brown@hesbynett.no> - 2016-09-18 16:27 +0200
                      Re: Continue with learning C Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-18 16:08 -0400
                    Re: Continue with learning C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-18 07:30 -0700
                      Re: Continue with learning C Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-18 16:07 -0400
                  Re: Continue with learning C David Brown <david.brown@hesbynett.no> - 2016-09-18 16:38 +0200
                    Re: Continue with learning C BartC <bc@freeuk.com> - 2016-09-18 16:37 +0100
                      Re: Continue with learning C Reinhardt Behm <rbehm@hushmail.com> - 2016-09-18 23:54 +0800
                        Re: Continue with learning C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-18 16:56 -0700
                      Re: Continue with learning C Richard Heathfield <rjh@cpax.org.uk> - 2016-09-18 17:05 +0100
                        Re: Continue with learning C "James R. Kuyper" <jameskuyper@verizon.net> - 2016-09-18 12:28 -0400
                          Re: Continue with learning C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-18 17:00 -0700
                        Re: Continue with learning C Alla _ <modelling.data@gmail.com> - 2016-09-19 01:40 -0700
                          Re: Continue with learning C "Osmium" <r124c4u102@comcast.net> - 2016-09-19 08:55 -0500
                      Re: Continue with learning C "Osmium" <r124c4u102@comcast.net> - 2016-09-18 11:31 -0500
                        Re: Continue with learning C Ian Collins <ian-news@hotmail.com> - 2016-09-19 07:25 +1200
                        Re: Continue with learning C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-18 20:36 +0100
                        Re: Continue with learning C "James R. Kuyper" <jameskuyper@verizon.net> - 2016-09-18 15:45 -0400
                        Re: Continue with learning C Rosario19 <Ros@invalid.invalid> - 2016-09-19 18:58 +0200
                      Re: Continue with learning C "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-09-18 09:55 -0700
                        Re: Continue with learning C "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-09-18 10:12 -0700
                        Re: Continue with learning C luser droog <luser.droog@gmail.com> - 2016-09-18 13:11 -0700
                      Re: Continue with learning C David Brown <david.brown@hesbynett.no> - 2016-09-18 21:54 +0200
                        Re: Continue with learning C supercat@casperkitty.com - 2016-09-18 15:58 -0700
                          Re: Continue with learning C Richard Heathfield <rjh@cpax.org.uk> - 2016-09-19 07:09 +0100
                          Re: Continue with learning C David Brown <david.brown@hesbynett.no> - 2016-09-19 10:04 +0200
                            Re: Continue with learning C BartC <bc@freeuk.com> - 2016-09-19 10:38 +0100
                              Re: Continue with learning C David Brown <david.brown@hesbynett.no> - 2016-09-19 13:29 +0200
                            Re: Continue with learning C supercat@casperkitty.com - 2016-09-19 08:04 -0700
                              Re: Continue with learning C Reinhardt Behm <rbehm@hushmail.com> - 2016-09-20 09:33 +0800
                                Re: Continue with learning C supercat@casperkitty.com - 2016-09-19 20:47 -0700
                                  Re: Continue with learning C David Brown <david.brown@hesbynett.no> - 2016-09-20 09:00 +0200
                                    Re: Continue with learning C Reinhardt Behm <rbehm@hushmail.com> - 2016-09-20 17:59 +0800
                                      Re: Continue with learning C Ike Naar <ike@iceland.freeshell.org> - 2016-09-20 17:24 +0000
                              Re: Continue with learning C David Brown <david.brown@hesbynett.no> - 2016-09-20 08:57 +0200
                                Re: Continue with learning C supercat@casperkitty.com - 2016-09-20 10:53 -0700
                        Re: Continue with learning C Reinhardt Behm <rbehm@hushmail.com> - 2016-09-19 13:19 +0800
                      Re: Continue with learning C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-19 01:30 +0100
        Re: Continue with learning C Alla _ <modelling.data@gmail.com> - 2016-09-19 01:15 -0700
    Re: Continue with learning C Barry Schwarz <schwarzb@dqel.com> - 2016-09-15 12:38 -0700
    Re: Continue with learning C fir <profesor.fir@gmail.com> - 2016-09-21 11:42 -0700
      Re: Continue with learning C fir <profesor.fir@gmail.com> - 2016-09-21 12:40 -0700
        Re: Continue with learning C fir <profesor.fir@gmail.com> - 2016-09-21 12:49 -0700
        Re: Continue with learning C fir <profesor.fir@gmail.com> - 2016-09-23 14:47 -0700
          Re: Continue with learning C fir <profesor.fir@gmail.com> - 2016-09-23 14:59 -0700

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

#93738

On 09/18/2016 12:05 PM, Richard Heathfield wrote:
...
> ... (I don't know how
> prevalent English is in Israeli culture).

See <https://en.wikipedia.org/wiki/Israel#Language>
"English was an official language during the Mandate period; it lost 
this status after the creation of Israel, but retains a role comparable 
to that of an official language,[298][299][300] as may be seen in road 
signs and official documents. Many Israelis communicate reasonably well 
in English, as many television programs are broadcast in English with 
subtitles and the language is taught from the early grades in elementary 
school. In addition, Israeli universities offer courses in the English 
language on various subjects.[301]"

See also <https://en.wikipedia.org/wiki/Languages_of_Israel#English>

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

#93770

On Sunday, September 18, 2016 at 5:28:48 PM UTC+1, James R. Kuyper wrote:
> On 09/18/2016 12:05 PM, Richard Heathfield wrote:
> ...
> > ... (I don't know how
> > prevalent English is in Israeli culture).
> 
> See <https://en.wikipedia.org/wiki/Israel#Language>
> "English was an official language during the Mandate period; it lost 
> this status after the creation of Israel, but retains a role comparable 
> to that of an official language,[298][299][300] as may be seen in road 
> signs and official documents. Many Israelis communicate reasonably well 
> in English, as many television programs are broadcast in English with 
> subtitles and the language is taught from the early grades in elementary 
> school. In addition, Israeli universities offer courses in the English 
> language on various subjects.[301]"
> 
Everyone speaks English except small children.

So it's often hard to insist on speaking Hebrew when you are not
very fluent.

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

#93784

On Sunday, September 18, 2016 at 7:05:42 PM UTC+3, Richard Heathfield wrote:
> On 18/09/16 16:37, BartC wrote:
> > On 18/09/2016 15:38, David Brown wrote:
> >> On 18/09/16 02:11, Richard Heathfield wrote:
> >
> >> For small enough pieces of software, or for software that is so critical
> >> that the cost of bugs is extremely high, the rounding may mean that you
> >> end up with zero bugs.  But for complex commodity software, you
> >> absolutely expect to ship with bugs.
> >
> > Didn't the Space Shuttle have multiple backup computers, one of which
> > was programmed by a different team to make sure they didn't share the
> > same bugs?
> >
> >
> >> It is not embarrassing - it is
> >> fundamental probability and economics.  To use Malcolm's earlier
> >> example, the customer in the USA does not want to pay twice as much for
> >> his word processor in order to be sure that customers in Israel can mix
> >> Hebrew and English without problems.
> >
> > And wasn't it Knuth who offered $250(?) for each bug readers discovered
> > in his algorithms?
> >
> > So we all expect to make mistakes. Except apparently Richard Heathfield
> > (unless his point was about knowingly shipping software with errors that
> > you don't tell the users about.)
> 
> Of course we expect to make mistakes. We even expect to make mistakes 
> that we don't know how to fix (or can't fix within budget). But we don't 
> (or rather, shouldn't) /hide/ from the user those mistakes that we do 
> know about.
> 
> For the USA release, it is sufficient to publish a note to the effect 
> that mixing Hebrew and English can cause problems (and to indicate what 
> kinds of problems those are).
> 
> That /may/ even be sufficient for the Israel release (I don't know how 
> prevalent English is in Israeli culture).
> 
> What is not sufficient is to ship the product /as if/ everything worked 
> fine if it's known that it doesn't. If customers are told before buying 
> that such-and-such a module doesn't work properly, and if they then 
> decide to buy it anyway, that's up to them. But if they are /not/ told, 
> then they have a case against the vendor.

Exactly. I wonder why that is not the widely spread rule, as it is in all other
businesses. 

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

#93799

"Alla _" wrote:

> On Sunday, September 18, 2016 at 7:05:42 PM UTC+3, Richard Heathfield 
> wrote:
>> On 18/09/16 16:37, BartC wrote:
>> > On 18/09/2016 15:38, David Brown wrote:
>> >> On 18/09/16 02:11, Richard Heathfield wrote:
>> >
>> >> For small enough pieces of software, or for software that is so 
>> >> critical
>> >> that the cost of bugs is extremely high, the rounding may mean that 
>> >> you
>> >> end up with zero bugs.  But for complex commodity software, you
>> >> absolutely expect to ship with bugs.
>> >
>> > Didn't the Space Shuttle have multiple backup computers, one of which
>> > was programmed by a different team to make sure they didn't share the
>> > same bugs?
>> >
>> >
>> >> It is not embarrassing - it is
>> >> fundamental probability and economics.  To use Malcolm's earlier
>> >> example, the customer in the USA does not want to pay twice as much 
>> >> for
>> >> his word processor in order to be sure that customers in Israel can 
>> >> mix
>> >> Hebrew and English without problems.
>> >
>> > And wasn't it Knuth who offered $250(?) for each bug readers discovered
>> > in his algorithms?
>> >
>> > So we all expect to make mistakes. Except apparently Richard Heathfield
>> > (unless his point was about knowingly shipping software with errors 
>> > that
>> > you don't tell the users about.)
>>
>> Of course we expect to make mistakes. We even expect to make mistakes
>> that we don't know how to fix (or can't fix within budget). But we don't
>> (or rather, shouldn't) /hide/ from the user those mistakes that we do
>> know about.
>>
>> For the USA release, it is sufficient to publish a note to the effect
>> that mixing Hebrew and English can cause problems (and to indicate what
>> kinds of problems those are).
>>
>> That /may/ even be sufficient for the Israel release (I don't know how
>> prevalent English is in Israeli culture).
>>
>> What is not sufficient is to ship the product /as if/ everything worked
>> fine if it's known that it doesn't. If customers are told before buying
>> that such-and-such a module doesn't work properly, and if they then
>> decide to buy it anyway, that's up to them. But if they are /not/ told,
>> then they have a case against the vendor.
>
> Exactly. I wonder why that is not the widely spread rule, as it is in all 
> other
> businesses.

Do you wonder why some software isn't accompanied by a little piece of paper 
that describes the rules and regulations wrt this software?  It seems to me 
that if something physical is passed, such as a CD, and the company is 
largish, such as Microsoft, there *is*  a piece of paper.  If not ( no CD), 
there is some virtual monkey business going on in the background that you 
haven't studied sufficiently.

My guess is that if your million dollar gizmo is destroyed because of some 
$300 software, you only get $300.  YMMV depending on where you live.  I 
think the phrase "limited warranty" is needed to dig deeper into this. 

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

#93739

"BartC" wrote:

> Didn't the Space Shuttle have multiple backup computers, one of which was 
> programmed by a different team to make sure they didn't share the same 
> bugs?

I don't think I ever heard that before, but if so, it could lead to some 
nasty side effects.

Imagine being on the shuttle and knowing you are going to die in a little 
while if you react wrongly.  Computer A says do X and computer B says do Y. 
What a terrifying way to die. 

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

#93745

On 09/19/16 04:31 AM, Osmium wrote:
> "BartC" wrote:
>
>> Didn't the Space Shuttle have multiple backup computers, one of which was
>> programmed by a different team to make sure they didn't share the same
>> bugs?
>
> I don't think I ever heard that before, but if so, it could lead to some
> nasty side effects.

It's common practice in safety critical systems such as flight control.

> Imagine being on the shuttle and knowing you are going to die in a little
> while if you react wrongly.  Computer A says do X and computer B says do Y.

That's why you have computer C.

-- 
Ian

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

#93746

"Osmium" <r124c4u102@comcast.net> writes:

> "BartC" wrote:
>
>> Didn't the Space Shuttle have multiple backup computers, one of
>> which was programmed by a different team to make sure they didn't
>> share the same bugs?
>
> I don't think I ever heard that before, but if so, it could lead to
> some nasty side effects.
>
> Imagine being on the shuttle and knowing you are going to die in a
> little while if you react wrongly.  Computer A says do X and computer
> B says do Y. What a terrifying way to die. 

The main flight system was designed for four or five computers (you get
two failures with five and can still get a single result by majority
vote) but the result of the synchronised computations are presented as
definite actions -- the shuttle turns, it's engines fire and so on.  If
no majority is possible, the system simply stops.  Since it's a
fly-by-wire system, this is catastrophic, but at least no one has to
make the sorts of decisions you describe.

Due to cost, the end design was for four synchronised computers, but a
fifth was also carried with more limited software.  This could bring the
shuttle down even if the main system failed.  Some flights even went out
with six computers -- two that could be used as stand-alone backups to
get the craft down and the main synchronised four.

This limited flight backup system was indeed developed by a separate
team (Rockwell won the contract) from the IBM team that developed the
rest (from specs generated by Rockwell, as it happens).  It's not clear
if this was deliberate or simply how the contracts ended up being
awarded.  Maybe IBM or Rockwell could have won both and the same team
that developed one system would them have written the other.  I don't
know.

I've heard is said that four were used because that is the minimum
number that can solve the Byzantine Generals Problem[1] -- synchronised
action in the face of unreliable autonomous agents -- but that's not the
case.  The main computers simply used majority voting between three,
switching the fourth in (manually!) when one of the three fails.

[1] If you fancy fun read (for some value of fun) you could do worse
than this which is one of my favourite papers:

Lamport, Shostak, and Pease, "The Byzantine Generals Problem" ACM
Transactions on Programming Languages and Systems, Vol. 4, No. 3, July
1982.
-- 
Ben.

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

#93750

On 09/18/2016 12:31 PM, Osmium wrote:
> "BartC" wrote:
>
>> Didn't the Space Shuttle have multiple backup computers, one of which was
>> programmed by a different team to make sure they didn't share the same
>> bugs?
>
> I don't think I ever heard that before, but if so, it could lead to some
> nasty side effects.
>
> Imagine being on the shuttle and knowing you are going to die in a little
> while if you react wrongly.  Computer A says do X and computer B says do Y.
> What a terrifying way to die.

<https://en.wikipedia.org/wiki/Triple_modular_redundancy>

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

#93816

On Sun, 18 Sep 2016 11:31:03 -0500, "Osmium" wrote:

>"BartC" wrote:
>
>> Didn't the Space Shuttle have multiple backup computers, one of which was 
>> programmed by a different team to make sure they didn't share the same 
>> bugs?
>
>I don't think I ever heard that before, but if so, it could lead to some 
>nasty side effects.
>
>Imagine being on the shuttle and knowing you are going to die in a little 
>while if you react wrongly.  Computer A says do X and computer B says do Y. 
>What a terrifying way to die. 

some program has to need to be bug free...
it is easy try one program result each input allowed
if input allowed is not too much big...

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

#93740

Bartc wrote:
> Didn't the Space Shuttle have multiple backup computers, one
> of which was programmed by a different team to make sure
> they didn't share the same bugs?

I remember reading that the Space Shuttle used four processors
to compute each calculation, and that all four had to agree or
the data was considered invalid.  I remember this being to
counteract soft errors in bitlines, the result of solar radiation.
I remember them also using processors on large feature size production
for the same reason, like 10,000nm 8086s and 3500nm 80386s.
I don't think I ever heard or read that they used software written
by different teams, but it would make sense.  And, I could be
wrong in remembering the four processors.  If I recall correctly,
it was in an article about things using the 80386 CPU, and why they
were using it.  275K transistors was one reason.

Best regards,
Rick C. Hodgin

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

#93742

Rick C. Hodgin wrote:
> I remember them also using processors on large feature
> size production for the same reason, like 10,000nm 8086s
> and 3500nm 80386s.

Correction:  Should be 3000nm 8086s and 1500nm 80386s.

I didn't think that sounded right. :-)

Best regards,
Rick C. Hodgin

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

#93755

On Sunday, September 18, 2016 at 11:55:09 AM UTC-5, Rick C. Hodgin wrote:
 If I recall correctly,
> it was in an article about things using the 80386 CPU, and why they
> were using it.  275K transistors was one reason.

IIRC, the Siemens LRV trains that run in St. Louis have at least
2 386s, one for doors and lights and general controls, and another
devoted just to the braking system[1], and possibly a third whose
porpoise I forget.

[1] The braking system was fairly complex with a first stage that
turned the motors into generator, a second stage with gearing stuff,
and the third actually engaged the padded forceps. 

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

#93751

On 18/09/16 17:37, BartC wrote:
> On 18/09/2016 15:38, David Brown wrote:
>> On 18/09/16 02:11, Richard Heathfield wrote:
>
>> For small enough pieces of software, or for software that is so critical
>> that the cost of bugs is extremely high, the rounding may mean that you
>> end up with zero bugs.  But for complex commodity software, you
>> absolutely expect to ship with bugs.
>
> Didn't the Space Shuttle have multiple backup computers, one of which
> was programmed by a different team to make sure they didn't share the
> same bugs?
>

I believe it is common practice in avionics to have three independent 
computers for the most critical parts.  Each board must have a different 
processor/microcontroller from a different company, and be programmed by 
independent teams using different development tools.  A majority voting 
system is used to determine the signals that are driven out to the 
actuators, with any differences of opinion leading to alarm bells.

>
>> It is not embarrassing - it is
>> fundamental probability and economics.  To use Malcolm's earlier
>> example, the customer in the USA does not want to pay twice as much for
>> his word processor in order to be sure that customers in Israel can mix
>> Hebrew and English without problems.
>
> And wasn't it Knuth who offered $250(?) for each bug readers discovered
> in his algorithms?

Many people and companies, including Knuth, have offered rewards for 
finding and/or squashing bugs.

>
> So we all expect to make mistakes. Except apparently Richard Heathfield
> (unless his point was about knowingly shipping software with errors that
> you don't tell the users about.)
>

Richard said it was embarrassing to sell software with bugs in it.  That 
is true - though it might be inevitable for most software to ship with 
bugs (known or unknown), and might be economically the right decision to 
ship even with known bugs, it is still embarrassing when bugs are found.

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

#93765

On Sunday, September 18, 2016 at 2:54:48 PM UTC-5, David Brown wrote:
> I believe it is common practice in avionics to have three independent 
> computers for the most critical parts.  Each board must have a different 
> processor/microcontroller from a different company, and be programmed by 
> independent teams using different development tools.  A majority voting 
> system is used to determine the signals that are driven out to the 
> actuators, with any differences of opinion leading to alarm bells.

A problem with that approach is that computers may select an action in
anticipation of being able to perform a certain future action; trying
to simply use a majority-voting scheme for arbitration may result in
irrational behavior, somewhat analogous to the way it would be possible
for 2/3 of the population to regard chocolate as better than strawberry,
2/3 to regard strawberry as better than vanilla, and 2/3 to regard vanilla
as better than chocolate.

> > And wasn't it Knuth who offered $250(?) for each bug readers discovered
> > in his algorithms?
> 
> Many people and companies, including Knuth, have offered rewards for 
> finding and/or squashing bugs.

My recollection of the story is that the check was for some lesser amount,
and that the value of the checks as collectors' items far exceeded their
monetary value that a relatively small fraction were ever cashed.

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

#93778

On 18/09/16 23:58, supercat@casperkitty.com wrote:
> On Sunday, September 18, 2016 at 2:54:48 PM UTC-5, David Brown wrote:
>> I believe it is common practice in avionics to have three independent
>> computers for the most critical parts.  Each board must have a different
>> processor/microcontroller from a different company, and be programmed by
>> independent teams using different development tools.  A majority voting
>> system is used to determine the signals that are driven out to the
>> actuators, with any differences of opinion leading to alarm bells.
>
> A problem with that approach is that computers may select an action in
> anticipation of being able to perform a certain future action; trying
> to simply use a majority-voting scheme for arbitration may result in
> irrational behavior, somewhat analogous to the way it would be possible
> for 2/3 of the population to regard chocolate as better than strawberry,
> 2/3 to regard strawberry as better than vanilla, and 2/3 to regard vanilla
> as better than chocolate.
>
>>> And wasn't it Knuth who offered $250(?) for each bug readers discovered
>>> in his algorithms?
>>
>> Many people and companies, including Knuth, have offered rewards for
>> finding and/or squashing bugs.
>
> My recollection of the story is that the check was for some lesser amount,
> and that the value of the checks as collectors' items far exceeded their
> monetary value that a relatively small fraction were ever cashed.

That's closer to the mark. Originally the bounty was $0.01. It doubled 
every year, until it reached $2.56, at which point Knuth exercised 
proper financial judgement by announcing a ceiling. (He immediately 
received a flurry of bug reports from people who'd been saving them up!) 
My own cheque was for $2.56. In latter days, the physical cheques have 
been replaced by an online roll of honour, "The Bank of San Serriffe" 
<http://www-cs-faculty.stanford.edu/~uno/boss.html>

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

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

#93781

On 19/09/16 00:58, supercat@casperkitty.com wrote:
> On Sunday, September 18, 2016 at 2:54:48 PM UTC-5, David Brown wrote:
>> I believe it is common practice in avionics to have three independent 
>> computers for the most critical parts.  Each board must have a different 
>> processor/microcontroller from a different company, and be programmed by 
>> independent teams using different development tools.  A majority voting 
>> system is used to determine the signals that are driven out to the 
>> actuators, with any differences of opinion leading to alarm bells.
> 
> A problem with that approach is that computers may select an action in
> anticipation of being able to perform a certain future action; trying
> to simply use a majority-voting scheme for arbitration may result in
> irrational behavior, somewhat analogous to the way it would be possible
> for 2/3 of the population to regard chocolate as better than strawberry,
> 2/3 to regard strawberry as better than vanilla, and 2/3 to regard vanilla
> as better than chocolate.
> 

No, that is not a problem at all.  There is no scope for personal
preferences in such a system.

When you use triple redundancy with majority votes, you make your
software and your hardware with a very tight specification.  When the
inputs are this, and the current state is that, the output of the
function/regulator/module/whatever shall be this - and it shall be valid
within this specific time interval.

No system gets to make guesses about the future, unless /all/ systems
are specified to make the same guesses in the same circumstances.  There
is no place for trying to make a "smarter" computer here - it is only at
the level of the specifications that people are allowed to be "clever".

The point is mainly to protect against run-time failures - single-event
upsets from cosmic rays, or hardware malfunction.  Different cpu designs
and different hardware designs avoid systematic failure, and different
programming teams mean that in the rare event of there being a design
fault or software bug that was not caught during testing, it will be
handled safely at flight time.

(The space shuttle folks skimped on this by using multiple identical
cpus, and, AFAIK, the same software on each.)

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

#93788

On 19/09/2016 09:04, David Brown wrote:

> (The space shuttle folks skimped on this by using multiple identical
> cpus, and, AFAIK, the same software on each.)

 From "Into the Black" by Rowland White:

"Still not entirely happy to trust in the machines, NASA also included a 
fifth, back-up computer, programmed not by IBM but separately by 
Rockwell. If a fatal software bug, endemic to the work done by IBM, 
somehow slipped through the net, the uncontaminated Rockwell machine 
would bring the Shuttle home."

-- 
Bartc

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

#93793

On 19/09/16 11:38, BartC wrote:
> On 19/09/2016 09:04, David Brown wrote:
> 
>> (The space shuttle folks skimped on this by using multiple identical
>> cpus, and, AFAIK, the same software on each.)
> 
> From "Into the Black" by Rowland White:
> 
> "Still not entirely happy to trust in the machines, NASA also included a
> fifth, back-up computer, programmed not by IBM but separately by
> Rockwell. If a fatal software bug, endemic to the work done by IBM,
> somehow slipped through the net, the uncontaminated Rockwell machine
> would bring the Shuttle home."
> 

So they got that one right!

I still think it was a poor decision to use identical processors in the
first four systems - you want to maximise the difference between them.

Modern safety-critical microcontrollers are often built with two
processor cores, operating in lock-step from the same inputs and
software, with detection of inconsistent outputs.  In some of these
devices, the two cores are the same design but physically oriented in
different directions (one core is upside down an 90° rotated with
respect to the other).  In others, the layout is completely independent
from the same hardware source code - all in the name of keeping the
logical operation identical, but the susceptibility to external
influences as independent as possible.

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

#93804

On Monday, September 19, 2016 at 3:05:00 AM UTC-5, David Brown wrote:
> When you use triple redundancy with majority votes, you make your
> software and your hardware with a very tight specification.  When the
> inputs are this, and the current state is that, the output of the
> function/regulator/module/whatever shall be this - and it shall be valid
> within this specific time interval.
> 
> No system gets to make guesses about the future, unless /all/ systems
> are specified to make the same guesses in the same circumstances.  There
> is no place for trying to make a "smarter" computer here - it is only at
> the level of the specifications that people are allowed to be "clever".

Many control systems inherently need to make estimates about future
behavior in order to decide what to do in the present.  But there may be
problems even in some immediate-present scenarios.  Suppose a system might
attempt to slow down by energizing either of two braking systems, but should
avoid energizing both.  The first controller thinks the primary brake is
sufficiently hot that it should use the backup brake instead.  The second
controller thinks the primary brake is fine.  The third controller is
malfunctioning and either doesn't think any braking is necessary, or thinks
both brakes should be applied.

Energizing the primary brake alone would be acceptable behavior.  Energizing
the secondary brake alone would also be acceptable behavior.  A majority-vote
system, however, would generate an unacceptable behavior even though only
one controller was malfunctioning.

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

#93832

AT Monday 19 September 2016 23:04, supercat@casperkitty.com wrote:

> On Monday, September 19, 2016 at 3:05:00 AM UTC-5, David Brown wrote:
>> When you use triple redundancy with majority votes, you make your
>> software and your hardware with a very tight specification.  When the
>> inputs are this, and the current state is that, the output of the
>> function/regulator/module/whatever shall be this - and it shall be valid
>> within this specific time interval.
>> 
>> No system gets to make guesses about the future, unless /all/ systems
>> are specified to make the same guesses in the same circumstances.  There
>> is no place for trying to make a "smarter" computer here - it is only at
>> the level of the specifications that people are allowed to be "clever".
> 
> Many control systems inherently need to make estimates about future
> behavior in order to decide what to do in the present.  But there may be
> problems even in some immediate-present scenarios.  Suppose a system might
> attempt to slow down by energizing either of two braking systems, but
> should
> avoid energizing both.  The first controller thinks the primary brake is
> sufficiently hot that it should use the backup brake instead.  The second
> controller thinks the primary brake is fine.  The third controller is
> malfunctioning and either doesn't think any braking is necessary, or
> thinks both brakes should be applied.
> 
> Energizing the primary brake alone would be acceptable behavior. 
> Energizing
> the secondary brake alone would also be acceptable behavior.  A
> majority-vote system, however, would generate an unacceptable behavior
> even though only one controller was malfunctioning.

Such redundant system only make sense if the software on each system is 
developed according to the same requirements. Having clear requirements 
should prevent our scenario. With clearly specified behavior there is not 
"the other controller thinks ...". If it "thinks" differently it is either 
defective or the software was not been developed according to the 
requirements.
Assuming that the software was developed as it should be, why should in your 
example the second controller come to a different conclusion about the state 
and usability of the primary brake? It has the same information about the 
brakes since it gets the same inputs. The software was developed to the same 
requirements so it has to come to the conclusions. There is - and may not - 
no random element in there. The only reason for such differences is a 
malfunction, either hardware or software.

Sometimes I get the impression, some people think such hi-rel software is 
thrown together by trial and error. I am writing software for avionics, 
there we have the DO-178. Other fields have similar regulations.
There are very tightly defined and controlled processes. You do not just 
start to code something. You do not even create an empty source file before 
the whole project has defined all project planning, requirements are 
developed and reviewed and approved, with clearly defined transition 
criteria from step to step, verification plans for each requirement are 
defined and then you can start to create first code.

-- 
Reinhardt

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

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

Back to top | Article view | comp.lang.c

csiph-web