Re: Continue with learning C

From	Reinhardt Behm <rbehm@hushmail.com>
Newsgroups	comp.lang.c
Subject	Re: Continue with learning C
Date	2016-09-20 09:33 +0800
Organization	A noiseless patient Spider
Message-ID	<nrq3l2$4v2$1@dont-email.me> (permalink)
References	(9 earlier) <nrmcav$p43$1@dont-email.me> <nrmrdp$gbl$1@dont-email.me> <b0a0a0f1-1f06-44ec-9614-e44b5ef011b9@googlegroups.com> <nro66t$nhe$1@dont-email.me> <c2903a40-202c-4296-9f95-6668b4429cd5@googlegroups.com>

Show all headers | View raw

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

Thread

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

csiph-web