The Railway System from a Software Architecture Perpective

What distinguishes a railroad from other transportation systems? It is the use of two rails to carry and guide the vehicles. From a system perspective, we can say that this is a client-server architecture. The rails are the server that provide two services to the vehicles:

These two services make the Railway System possible. As in a software system, there exist different protocols for these services. In the Railway System, it is called a gauge. This is the distance between the two rails.

All vehicles that implement this protocol can run on all tracks that implement this protocol. The track hides the implementation details of the server interface – the vehicle does not need to know whether the track is made with ballast and sleepers or entirely of concrete. As long as the gauge matches, you can put a vehicle on a track.

The most widely used gauge in the world is 1435mm. It was established as a defacto standard by George Stephenson. He created the first viable Railway System. The locomotive works he founded exported materials and vehicles all over the world. This is why most railways in the world now use this gauge.

But this is not the only standard in use. There are good reasons to use different standards.

Many railways in the Swiss Alps have a gauge of 1000mm. Construction of tracks, tunnels and bridges in a mountainous region is much cheaper for a smaller gauge. But it also reduces the capacity of the system.

Russia, on the other hand, uses a broader gauge of 1520mm. The reasons for using a broader gauge then in the rest of Europe were mostly strategic. In case of an invasion it should inhibit the use of the infrastructure by the invader. This forced the invading German forces in World War II to perform a major rework of the Railway System to adopt it to their own standard. But nowadays, the choice of this standard slows down the intercontinental freight trains between Europe and Asia.

Interoperability between these standards is possible. There are vehicles that can adopt different protocols by changing their gauge. There are also mixed-gauge tracks, allowing vehicles of both gauges to pass. As both solutions require heavy infrastructure investments, it is most common to just unpack the content of the vehicle and transfer it into a vehicle using the different standard. Containerization has made this process much easier for freight, but for passengers this is still a major hassle.

The interface between rails and vehicles has evolved in a backwards compatible way. The weight and speed of trains has increased steadily. This means the capabilities of the track had to increase in the same way. Modern trains can only run on tracks that fulfill the minimum requirements in weight capabilities. But the other way round, an ancient train could run on the latest high speed track.

In the Railway System, one or more engines pull multiple cars that carry freigt and passengers. The vehicles are connected with couplers and buffers that transfer the push-and-pull forces throughout the train. Thus we can view a train as a peer-to-peer network.

The protocol for this P2P network has evolved in a backwards-compatible way. In the beginning, only the forces were transmitted. After a while, the braking system was included. The necessary hoses were added to the interface, without changing the couplers. The same was done with heating energy, electrical energy and nowadays information transfer. As there was always a backwards-compatible upgrade path, the introduction of new capabilities to the interface throughout the whole fleet of railway cars could be accomplished.

But the legacy of this interface also has its drawbacks. In Europe, the couplers have to be connected manually even today. This process is very costly and takes a long time when handling trains in a classification yard. Automatic couplers like the ones that are used in North America would make the whole process much easier. But the transition to the automatic couplers has not been performed yet in Europe, as there is no upgrade path. All vehicle would have to change at once. That is a very daunting proposition in a network spanning a whole continent.

Of course, there are many more interfaces in the Railway System, and many of them are less standardized.

For instance, the voltages for electric railways differ from country to country, sometimes even within the same country. And the same is true for train control systems.

In the past, these differences enforced a change of the engine at the border. Nowadays, railway suppliers offer engines that implement different voltage and train control “protocols”, so they can travel cross border. It makes the engines more costly, but it makes cross-border travel much easier than in the past.

The success of the Railway System over the last 200 years shows that technical systems can evolve over a very long time frame while constantly being in use.

Much of that success is due to the stable interfaces. Once the basic interfaces rail/wheel and engine/car were stable, engines, cars and track could evolve independently from each other. The market for vehicles was opened to many suppliers, and railway companies could send their trains on other companies’ tracks. Without this interoperability, no railway networks could have evolved.

On the other hand, stable interfaces are often very hard or impossible to change. As soon as the interfaces are widely adopted, they cannot be changed without backwards compatibility.

This story contains important lessons for computer systems. A stable and flexible interface technology enables constant and independent growth of connected computers. The best example of a system built in this way is the Internet. With TCP/IP as transport protocol, every company can build computers that can connect to it, and all computers can evolve independently from each other. The same is true for the underlying physical layers.

But as the Internet has become ubiquitous, it has become much harder to change its fundamental design decisions, like in the Railway System. All the design flaws that nobody could foresee at its birth will hardly ever be changed. Every fundamental change would exclude all devices from access that cannot be upgraded.

We can learn from this parable that it might not be possible to foresee all the future challenges and uses of a technical system. But if the system is flexible enough, it can be adapted again and again to have a very long lifetime.