The DataBeaver's Domain

Model railway - Software

Designing and operating a large model railway setup would be near impossible without some sort of help to see how the track geometry fits together and where each turnout is. There are different tools available for these tasks, including track stencils, miniature mock-up track pieces, switching panels and software products, both commercial and free. However, I had my own plans.

Being a programmer of the do-it-yourself variety, the natural choice was to write my own software suite. I had this crazy distant goal of being able to play an adaptation of Railroad Tycoon on my model railway. In fact, that's still a vision I hope to achieve one day.

At the core of my software suite is a set of libraries implementing a virtual layout and trains, 3D view of them and remote control over TCP/IP. There are two main programs: planning ("designer") and operation ("engineer"). In addition there are smaller utilities, including a program for generating shopping lists based on a layout file and current inventory, and some remote control clients.

The designer allows planning a layout with an unlimited supply of tracks. Various tools like cloning entire sections of tracks and snapping them into free endpoints speed up building complex layouts. Grid-based heightmap terrain can be created, though tracks will just as happily hang aroudn in empty space. Turnout and sensor IDs of tracks can be indicated for operating the layout. Routes and zones can be defined for automatic operation.

The engineer is used to run trains on a layout made with the designer. There are three main modes of operation. Trains can be run freely, taking whatever path turnouts are set to. A route (as specified in the designer) can be selected for the train to follow; if the train is not on the route it will find its way to it. And finally, there's a timetable system for fully automatic operation. Any of these may be selected on a per-train basis. In all cases, traffic control makes sure that trains won't collide.

On startup, the engineer displays a top-down view of the layout and a single window for overall layout control. Additional windows can be opened to control particular aspects of the layout, primarily trains. Turnouts can be switched by clicking on them. All windows can be moved around the screen, and all except the main control window can be closed.

The underlying library features a driver interface for supporting different command stations. At the moment there are drivers for Intellibox, Central Station and my own control device. A dummy driver also exists for testing new features without a physical layout.

Collectively this set of software is called R²C², for RailRoad Computer Control. When referring to just the libraries, it can also mean RailRoad Control Core.

Traffic control

The traffic control system follows that of real railways and uses absolute block signaling. The layout is automatically split into blocks based on sensor tracks. Turnouts can't have sensors, so the system has to deal with sensorless runs of track as well. It is also impractical to cover every possible centimetre of track in sensors

When a train is active, it tries to reserve blocks in front of it up to three sensor blocks. A minimum reservation distance is also observed in order to keep moving at the set speed. A simple AI monitors the amount of reserved track and adjusts speed accordingly; the train must always be able to stop within the reserved length of track. If the reserved blocks are running out, speed is first decreased and finally the train is stopped to wait for more blocks to become available. The reservation procedure is invoked again every time the train triggers a sensor and on some other occasions.

With sensorless blocks, the system has to rely to estimates. As soon as a train enters a sensor block, all reserved sensorless blocks ahead of it are also marked as current. Behind the train, sensorless blocks are freed when the last car has advanced a sufficient distance into the next block.

If a sensor is triggered in an unexpected way or if a train does not trigger a sensor it's supposed to, the system will immediately halt all trains as a safety measure.

Train speed and position

In addition to traffic control, sensors are also used for determining the actual speed of the trains. When a train triggers a sensor, the time is noted, and when it triggers the next sensor, its speed is calculated. The results for each speed step are stored separately, and each is accompanied by a weight value for refining the speed as new data is gathered. If the train's speed setting changes in between the sensors, the measurement is suppressed, as the result would be representative of neither the old nor the new speed.

When a new train is introduced, the system won't have any speed data for it. Since the control interface is based on real speeds, it will refuse to run the train at a speed step too far above the highest known one. Running the train around a loop a few times at the desired top speed is enough for the system to learn the necessary speed steps for correct operation.

The knowledge of actual speeds corresponding to speed steps can be used for accurate positioning of the virtual trains. When the train triggers a sensor, it is immediately moved to that position. Between sensors, it is advanced based on the gathered speed data.

Automated traffic

Even with traffic control, driving more than a few trains by hand is very difficult. To cope with more complex traffic, two automation subsystems are provided. The first of these is route planner. Given a destination, it will find a route to it from the train's current position. If multiple trains are being routed at once, the planner makes sure they won't end up in a deadlock situation.

The second automation subsystem is timetabling. Trains can be given a list of instructions, including departure times and destinations. Internally timetables make use of the route planner to set the routes. A clock with an adjustable rate is provided to base timetables on.

3D models

All the 3D models of locomotives and cars are made by me, using both the scale models and photographs of their real counterparts as reference. There are two generations of models, the older ones having around 300-1500 faces and a single color per model, while the newer ones have 5000-10000 faces and proper materials. Some of the more complex locomotives can have more than 20000 faces. I plan to eventually redo all old models with the new level of detail. However, I seem to acquire new rolling stock faster than I can model them.

Source code

All of the software is open source under the GNU Public License. Git access is available at git.tdb.fi. There are no official releases at the moment, nor are any planned.