Interlocking In A Box

One of the new projects we are working on is an “Interlocking In A Box” – a simple, yet flexible piece of signal logic designed to control an automatic interlocking for a diamond on a model railroad.  The idea came from one of the mail lists I’m subscribed to and we have been working on refining the definition and designing the signal logic over the past several months.  I figured now would be a good time show everyone where we are headed and maybe get some feedback.

Eventually, we plan to offer a complete, assembled and tested system for sale as the MRB-IIAB (MRBus enabled Interlocking In A Box).  It will be based on the MRB-XIO hardware, with an optional MRB-FCM running updated firmware to simulate trains on dummy crossing tracks.

grinnell-autolock

Automatic Interlocking in Grinnell, IA (Photo by N.D.Holmes)

Architecture

The original request was for a single mainline crossing another (dummy) single mainline.  On the real mainline, there is also a siding on one side that affects the signal indications shown on the point-end home signal.  This is a very simple case, so we decided make it a little more generic in the final implementation.  We allowed both tracks to be real and both to have provisions for a siding.  Simulated trains can appear on any track, from any direction.  Also, signal indications are generic, allowing 3 lights to be driven per signal, for future expansion to take into account occupancy in blocks ahead or any other signal standards.

schematic

Being an Interlocking in a BOX, our goal is simplicity.  Out of the box (no pun intended), the product should be able to operate with minimal configuration.  But, we also want it to have enough flexibility to accommodate a variety of situations.  This is always going to be a balancing act.

Hardware

The primary piece of hardware required is the MRB-XIO.  This board provides 40 input/outputs lines, a microcontroller, and an MRBus interface.  The interlocking logic will run on this board, taking in block detector and turnout position inputs and driving the signal outputs.  The interlocking board is set up to run a complete interlocking with real trains on each track.  It can also simulate trains on any track, in any direction, when connected via MRBus to an MRB-FCM fast clock master.

Block detection can come from a variety of sources.  The MRB-IIAB is able to interface directly with any optical or current-based detectors that provide logic-level outputs, including the MRB-BD4X detectors.  It will also be able to accept detector status over the MRBus network.

Prototype

Yes, there is real hardware!  The MRB-XIO running the IIAB code is on the bottom.  An MRB-CI2 is on the top and is used to interface the IIAB to a PC (via MRBus) for test and debug purposes.

mrb-iiab-prototype

Test Cases

To mentally test (brain sim) the various situations that might be presented to the Interlocking In A Box, some test cases were put together.  These will also be used to verify the design during development, help communicate its operation to others, and develop custom solutions when requested.

First up are some basic situations (Note: east/west is equivalent to north/south – the logic is symmetric and these cases apply equally well to either case):

Eastbound on main

Eastbound on siding

Eastbound arrives to opposing turnout

Westbound takes main

Westbound takes siding

Next are some meets at the interlocking:

Eastbound train arrives, but waits for a meet before going through the interlocking.

Westbound arrives, goes through the interlocking, then waits for a meet.

Real train arrives before simulated train.

Simulated train arrives before real train.

Four programmable delays are provided for enhancing realism and making single-point optical detectors operate more realistically:

TIMELOCK: After a signal drops from green to red, a fixed delay is observed before any signal can go back to green. This also applies when a turnout is changed.

LOCKOUT: After passing through the interlocking, a lockout period is observed where the train, now on the opposite side, cannot be detected as “new” train approaching from that direction.

TIMEOUT: When optical detectors are used, trains present in a block may not always be detected. A timeout is used to “coast” through these period of non-detection. Once a train is detected, the detector must remain in the no-detect state for the timeout period before the interlocking assumes the train is no longer present.
This also affects the situation where a train momentarily enters the approach block but then leaves (for example, switching a yard).

DEBOUNCE: With behavior similar to the timeout timer, the debounce timer applies to the interlocking block. It makes sure when the interlocking detector says the block has just cleared, it really is clear.

State Machine

For those who get a thrill from these sorts of things, a copy of the state machine diagram is available below (click for larger version).  This is current as of today, but may change over time as test cases are run, bugs are fixed, and new features are added.  However, it gives an idea where we are headed.  The latest can always be found in the MRBus SVN repository in the mrb-iiab/doc/ directory and the corresponding code in the mrb-iiab/src/ directory.  That same repository also has all the design files for the MRB-XIO hardware.

statemachine

Test Track

No model railroad electronic product would be complete without a test track.  The track has been laid and wiring added.  An MRServo-2 will be used as the turnout controller.  Signals and block detectors will also be added.

test-track

To keep things simple (and save some expense), we only have one siding.  Since the control algorithm is symmetric and does not distinguish between main and crossing tracks, this should not be a problem.

Testing

Since this is a moderately complex piece of signal logic, some form of testing was desired to make sure we meet the requirements and don’t break anything as features are implemented or new features are added.

First, a control panel display was implemented in software.  This is a simple “ASCII art” display that reads status information from an IIAB node via its MRBFS driver and displays it in a terminal window.

Second, a set of regression tests are being written, first to cover the test cases shown above, then to add other areas of concern.  This test platform provides an automated way to verify that the IIAB is doing what it should and, more importantly, isn’t broken when making changes or adding new features.

The video above shows real tests being run on the actual hardware.  The first test is a westbound taking the main.  The second test is a northbound taking the siding.  The code for both the control panel display (panel.c) and the regression testing (test.c) can be found in the mrb-iiab/src/test/ directory in SVN.  Keep in mind that this is very much a work in progress, but (constructive!) comments are always welcome.

Conclusion

We hope you find the Interlocking In A Box interesting and maybe even have a use for it.  If you are interested in using this design, please keep in touch and look for updates as we progress with the design.  If you have any questions or suggestions for improvements, please also share them, either using the comment section below or via email.

2 thoughts on “Interlocking In A Box”

  1. The “interlocking in a box” is an interesting solution to building a modern CTC-type control for a crossing with sidings. I wonder if it would be equal to operating a double-track wye with crossovers. My plan to model the SP Sacramento Division includes 3 wyes (Roseville, Elvas, and Davis) as well as and interchange (Marysville) with single tracks and wye legs. Could the IIAB be made to manage these situations where right-hand running requires crossings into and out of the wye? Also, could DCC interface allow dispatcher (DTC) to override IIAB ops?

    1. The IIAB is currently being targeted at a simple, automatic crossing-type interlocking. I doubt that the stock code would directly drop into the scenarios above. However, the hardware should be more than capable of doing what you need but it would likely be a custom software design. Contact us by email with your specific requirements on how you would like it to work and we can discuss more.

      In the spirit of being a simple automatic interlocking, the basic IIAB won’t have override controls. But we do have plans to make a future version that is dispatcher or operator controllable.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>