The future of interlocking design automation for modern railroads

What do infrastructure managers need to produce before they can start an interlocking design automation process?

They need to produce an internal go-ahead for standardisation and generalisation. It is less important to set out exactly what this standard should look like – although it is beneficial if they produce specifications – and is very common to arrive at the new standard in an agile way, such as implementing ideas and testing them in simulators.  A first step would be to document the object model, such as creating a list of all the physical objects (signals and switches) and abstract objects (routes) as well as their relations and interfaces. This is often the easiest part to specify as you need not know the function in full to be able to specify the interfaces. An object model of great detail is a perfect start for a more interactive process where safety requirements and functional requirements are detailed, using the terminology given by the object model.

What training do engineers need in order to use interlocking design automation tools?

For the Specific Application process, not more than two days of training are required. However, this presupposes that they have enough domain knowledge to understand the input data to the process – normally drawings and tables. In theory, not even that is required – they could simply enter the data in the tools without understanding what they are doing. Yet they will likely make some mistake and if they don’t have the domain knowledge, they will not notice their mistake and  know how to fix it. For engineers who also want to contribute to the Generic Application development, it is necessary to know the specification language used. This takes perhaps a couple of days to learn.

When would infrastructure managers start to see the financial benefits after implementing a modern interlocking system?

If you do five interlockings with the same signalling principles you could be fairly certain to see the benefits. In practice, benefits can often be seen much earlier because some data inevitably changes during the project and with an automated process you need not start all over again, but can simply change  data. For example, we had a customer who needed to change a distributed system from four to five controllers. This would have caused a lot of extra work requiring manual coding, but thanks to an automated process we could simply amend a configuration table and generate a new programme. In circumstances such as this, benefits are realised immediately.