@G3750 posted:There's a spot on the Panhandle where the Weirton Steel Yard exits onto the Westbound Mainline. This is a place where I needed an interlocking set of signals. The area is protected by an MTH signal bridge on the mainline and a Z-Stuff signal for the yard exit. The correct (desired behavior) was:
- When the switch is thrown for the mainline, the MTH signal (mainline) should show CLEAR and Yard signal STOP.
- When the switch is thrown for the yard exit, the MTH signal (mainline) should show STOP and the Yard signal CLEAR.
- When the track west of the signal is occupied, BOTH signals should show STOP.
The mainline stretches left into the distance beyond the MTH signal bridge (indicating STOP). The Weirton Steel Yard exit is to the right (with the decapod sitting on it). The DZ-1060 indicates CLEAR.
Again my thanks to Bob!!
George
George,
Excellent!
As much as we're thankful to Bob for helping to sort it out, I'm sure that he'd agree that your description of the situation was critical to him doing so.
All of us here at times deal with the complex interaction of events, during which a number of things need to occur in the correct order, and with the correct timing, for success to occur. This is a good example.
You may not realize this, but your description is superb, in fact it's almost perfect.
Folks who design safety-critical systems, such as railroad signals, must be precise and very, very clear when describing what must happen, and when. Using natural language, like English, German or Japanese, is usually very imprecise because it wasn't created for the purpose; it's too general in nature.
These are three basic "rules" used to determine if a requirement written in natural language is as good as it can be:
1.) It must be precise and unambiguous, that is, it can mean one, and only one, thing, and that thing must be very clear. The vast majority of people reading it must agree on precisely what it means. More than one interpretation must not be possible.
2.) It must be testable. There must be a way to verify that what is written is actually happening.
3.) It must contain either the word "must" or the equivalent "shall", insisting that there is no option as to whether to do it.
You've hit the nail on the head with (1) and (2) and almost nailed (3) as well ("should" doesn't quite cut it).
Congratulations.
Now, why do I bring this up?
In general when starting a new post, or adding an existing one, when we describe a situation that we need help with what we write is critical to others understanding what is actually happening. This is ultimately important to us getting a precisely targeted and accurate response.
Before hitting the "Post Reply" button, especially with a very technical problem, all of us should put in a little extra effort to make sure that what we write is also precise, clear and unambiguous. Write it once and read it. Does it capture the situation accurately? Can it be misinterpreted? Is there enough information? Did I forget to include something?
Even changing a word here and there, if you need to, can make a big difference.
It takes some practice to get good at this, but in the end it will help our talented and skilled technical folks, like Bob, to help us, precisely, quickly, and optimally.
When you look at the responses you get back to a technical question you've posted you'll see that the best of them were written by folks who practice this, perhaps without even realizing it.
Thanks George, and Bob too of course.
Mike
