-- Pascal Costanza University of Bonn mailto:costa...@web.de Institute of Computer Science III http://www.pascalcostanza.de Römerstr. 164, D-53117 Bonn (Germany)
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?
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 <ca167c61.0306290554.1ada4...@posting.google.com>, carh...@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?
>>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.
|
