Forgot your password?
typodupeerror
Software

+ - When 'can never happen' nearly kills-> 1

Submitted by
Peter (Professor) Fo
Peter (Professor) Fo writes "An piece of earth-moving machinery was being transferred from road mode to rail mode. This involves bringing a set of hinged flanged idler wheels down onto the rails so the machine rides on them. To power and brake the machine when on the track the idlers are squashed up against the road tyres. The system logic is designed so that either the front or back wheels must be in either fully 'road' or fully 'rail' position to provide braking. That is you can't move one end through the on/off motion which leaves the idler wheel on the rail without braking from the tyre. This interlocking seems a good idea by forcing the unsafe state to happen one end at a time only. But somehow, possibly contamination of a potentiometer, the vehicle found itself in two half complete operations which left if free to run away and crash into a stationary train. (See page 36 for sequence of events.) Neither end could be moved to a safe position because each was interlocking the other. The operator was seriously hurt. The moral of the story is "Can never happen" does happen and you better have a way to deal with it safely."
Link to Original Source
This discussion was created for logged-in users only, but now has been archived. No new comments can be posted.

When 'can never happen' nearly kills

Comments Filter:
  • Designing software defensively - having contingencies in place for all potential states regardless of how "possible" it is for the system to get into such a state is good software engineering. But rarely done, especially by engineers fresh out of college. Sometimes all it takes is one seemingly minor change to the source to make the impossible now possible.

    So, I'd like to vote this story up. But, in an ironic twist, the recent slashdot redesign seems to have made it impossible to vote stories up or down

1 Dog Pound = 16 oz. of Alpo

Working...