A good article: http://www.jot.fm/issues/issue_2003_05/column1
Pascal
--
Pascal Costanza University of Bonn
···············@web.de Institute of Computer Science III
http://www.pascalcostanza.de R�merstr. 164, D-53117 Bonn (Germany)
Pascal Costanza wrote:
> A good article: http://www.jot.fm/issues/issue_2003_05/column1
I actually had the good fortune to meet Dave Thomas at Richard Gabriel's
first Feyerabend workshop. He was looking for a way to increase diversity
in computing technologies and education then and I'm glad to see him
continuing this work now. I hope it will bear fruit in the future. Along
similar lines, Robert Glass has an editorial in this month's IEEE Software
stating why he thinks it would be a good idea to allow non-PhD's into CS
departments (at least for the purposes of teaching Software Engineering).
These days, though, I'd settle for a way to get enough jobs in the US
software industry so that good people weren't going without jobs. Who
needs more education in the area when the industry can't absorb the grads
we already have?
faa
Actually, what the term reminded me of, something that the
author probably did not intend, was ... N-version programming
for software fault tolerance.
That is, if you are building some critical piece of
software, e.g., for flight control, that computes some
result, you get N persons or groups to code N versions,
same or different language, algorithm, whatever.
If N=2 and the result differs, then you won't know
which to believe, but at least you will know that
at least one program could have a bug. If N=3, then you
can vote as in the famous TMR (Triple Modular Redundancy)
approach to hardware fault tolerance.
In article <····························@posting.google.com>,
·······@yahoo.com (c hore) wrote:
>That is, if you are building some critical piece of
>software, e.g., for flight control, that computes some
>result, you get N persons or groups to code N versions,
>same or different language, algorithm, whatever.
>
>If N=2 and the result differs, then you won't know
>which to believe, but at least you will know that
>at least one program could have a bug. If N=3, then you
>can vote as in the famous TMR (Triple Modular Redundancy)
>approach to hardware fault tolerance.
In Triple Modular Redundancy, are there feedback-based
mechanisms for learning over time? That is, if one
program is consistently overruled by the other two, is
there some weight on its contribution that's adjusted
downward, is it swapped out when a replacement program
becomes available, etc?
Or is its divergent perspective valued and kept around
solely for the contrarian outputs it contributes?
sv0f wrote:
> In article <····························@posting.google.com>,
> ·······@yahoo.com (c hore) wrote:
>
>
>>That is, if you are building some critical piece of
>>software, e.g., for flight control, that computes some
>>result, you get N persons or groups to code N versions,
>>same or different language, algorithm, whatever.
>>
>>If N=2 and the result differs, then you won't know
>>which to believe, but at least you will know that
>>at least one program could have a bug. If N=3, then you
>>can vote as in the famous TMR (Triple Modular Redundancy)
>>approach to hardware fault tolerance.
>
>
> In Triple Modular Redundancy, are there feedback-based
> mechanisms for learning over time? That is, if one
> program is consistently overruled by the other two, is
> there some weight on its contribution that's adjusted
> downward, is it swapped out when a replacement program
> becomes available, etc?
>
> Or is its divergent perspective valued and kept around
> solely for the contrarian outputs it contributes?
In avionics systems, any such discrepencies are logged either in srvice
or as part of the built-in-test at power on. The offending unit is then
replaced at a time dependent on its criticality (before next flight,
within the next n-hundred flying hours etc.). Some systems use inflight
monitoring to offline a repeatedly divergent unit, going from n-way
redundancy to (n-1)-way.
In some of the petro-chem and nuclear emergency plant shutdown systems
I've worked on, the n-way redundancy was complimented by running short
pulses throught the system, which would be passed through the logic but
not persist long enough to trip it, and these transient outputs
monitored for comparison with a seperate computer model of the logic to
show up any faulty units.
Pete