8 Interlocking Interlocking, named from the mechanical interlocks on older signal boxes is the process of ensuring that turnouts and signals cannot be set in a manner that permits collisions (assuming of course that the train drivers can see the signals and that they also obey the signals). In the early days of interlocking the signalman functioned as the local controller. He was the 'computer' following a pre-defined multi-threaded 'program' (the timetable). He acted on sensor input (his eyes, possibly track-based detectors, and messages from adjacent controllers). Having processed the inputs in accordance with the program the signalman generated outputs in the form of setting levers and sending messages to other signalmen. Ok, I accept that this description makes the signalman's job sound like an automaton, but thats exactly what it was - only it required a lot more intelligence and training than most factory workers because the signalmans program was multi-threaded (one thread for each train approaching his area, in his area, or departing his area) whereas a factory workers task were (and are) often single threaded (follows a single set of instructions from start to finish, then starts again). Modern signal boxes are no different really. Sure the levers have turned into tiny switches, and then have turned into touch sensitive computer screens. The mechanical interlocking is now just data in a computer. The signalman can now be a true automaton - he can let the computer handle everything. The signalman only takes over if he wants something to do, or if things get a bit hectic for the computer to handle (like last minute rescheduling or some other excitement). A model railway can (and should) immitate this interlocking in some way. You can of course build mechanical interlocking into a miniature set of levers that control turnouts and signals, but that is a skill way beyond most of us. Most model railways are interlocked purely by human overseers, but then of course they are restricted to only having a couple of trains moving at a time. These notes, however are targeted at assisted layouts where some kind of inanimate computer plays some role which probably includes interlocking. Interlocking is just one layer in a multilayer jungle and the implementation of interlocking depends upon what other layers are being automated. Interlocking requires input from higher layers (the timetable, or equivalent) and from lower layers (the track sensors). It might even have input from peers (other interlock systems handling different parts of the layout). The outputs obviously have to control turnouts and signals and might also control train speeds, where trains stop and isolate sections of track to prevent errors. A purist would say that the interlocker only controls the signals, and the signals control trains stopping and dead sections. Well thats true, but if you haven't got any signals and you have interlocking controlling virtual signals that control the track, then is there any difference. In a timetabled and route-planned system (such as the prototype) the required routes and timings are known in advance and typically the system will reserve several blocks of track for a moving train. In a non timetabled system where train movements are decided as the train moves around the track the interlocking will cover the smallest possible movement and pass the train onto the next section. So in short the higher layer input into the interlocking software could come from one or more of three sources: 1. A timetable (prototypical) 2. Local track routing decisions (random decision maker) 3. Human interface (on-the-spot decisions where to send your trains) And of course each local control area (what used to be a local signalbox) can take input from different sources if you wish. Internally, an interlocking function needs to keep track of which track sections are in use, for which trains, and exactly where those trains are. Knowing where the trains are is the task of the train follower (section 7) and this knowledge is the input we need from the lower levels. There are of course many ways of keeping track of which sections are in use for each train, where each train is going etc, but the way I choose to do it is as follows: Each section of track has a state, and is associated with one train. The train association is described in section 7 - the train follower. When the track section is not in use, and is not expecting a train its state is 'Free'. When a section needs to be be reserved for a train expected soon, then the state is set to 'Booked'. Further states depends upon what sensors you are using and whether the computer is driving the trains. The following list may seem to be more states than absolutely necessary, but they all help ensure that collisions are avoided. When a train is detected entering a section, preferably with an optical sensor then the section is said to be 'Arriving'. When a section enters the arriving state we need to ensure that the next section down the line can be booked for us, otherwise the train will have to start decellerating and stop before the end of the section. When a train is wholly within a section, and not overlapping either adjacent section then the section can be 'Occupied'. This indicates to the previous section that the train has safely departed and that previous section is now Free for use by another train. When a train has started leaving the section, and also is no longer entering, it can be labelled 'Departing'. Departing, like Occupied tells the previous section it is now free. If a train that is longer than the track section passes, then the track section will go from Arriving to Departing without ever entering Occupied state because the train was never wholly within the section. I accept that this behaviour is utterly non-prototypical (or at least I assume it is), because on a model the track is foreshortened much more than the trains are, and so it is usually impractical to ensure that trains fit within all track sections. You can simplify this whole state machine to just Free and Booked if you only use track circuiting and have conductive axles. If the computer is driving the trains then you need to keep a whole track section free between trains, and train must slow down and stop as soon as they are detected entering a section. The states I use, the arrangement of sensors and the script statements I use to follow trains and avoid collisions is defined and illustrated in: merg/files/layout controls/modular control/merg1.sdp or .ppt. I have not separated the train following code from the collision avoidance/interlocking code, but if you only want one or the other the two functions are separable. Although I appreciate that nearly everybody has different ideas, requirements and procedures for a model railway I believe that representing the functions you require in the script language I use can give you a real insight into how you actually want your layout to behave.