Sam Sherwood-Hale spoke to Colin Johnson of D/Gauge about the D/Gauge Rift, gauging software and the answer to the question: ‘why doesn’t the train fit’?
You are hosting a D/Gauge Rift launch event on 8 June, tell our readers what they can expect from the event.
The launch event is a celebration of the innovation that has been happening within D/Gauge for clearance assessment. For the last 24 months we’ve been working on game-changing clearance assessment software to make gauging simpler, faster, and smarter. There is an element of safety in there too, as there is a much simpler interface with less opportunity to make mistakes.
The event itself is going to be exciting and full of variety! We’re starting with David Johnson, Technical Director (and gauging guru), who will look at the history of gauging software and what the future of gauging looks like for the railway. He’s followed by a software demo to see the phenomenal D/Gauge Rift software, guest speakers from Bonner Rail and a live Q&A session to finish it off. It’s going to be great to get the industry together (although unfortunately not physically) to celebrate innovation in gauging. I’m very proud to be leading this new phase of D/Gauge’s contribution to the gauging world.
What was the inspiration behind developing D/Gauge Rift?
We have been batting off requests to make faster gauging software for the past decade. Speed, however, is only one aspect of the gauging process that was really in dire need for modernisation. As the volume and complexity of gauging datasets grew, the audience for gauging results changed and the availability of data developed. I knew we had to approach gauging assessment in a very different way, especially to future-proof it.
Gauging calculation has had a bad reputation for some time, as something that is overly complicated and far too cumbersome which I feel is a little harsh. The reality is that gauging calculations have a lot of parallels with tax calculation. In some way they are both a necessary ‘evil’ – leave it too late or get it wrong and there are significant adverse consequences – they each have significant nuances and complexities.
So having lived and breathed gauging for a decade, I knew that routine gauging activities could be simplified. You don’t have to be an expert in gauging to assess your designs, you simply need a simple and straight forward way to evaluate if the resultant space around the train is acceptable.
I do believe that there is a social and environmental responsibility to gauging. If gauging is overly conservative we inherently incur more track maintenance or more infrastructure change. Conservative gauging doesn’t just come from the methods, but also the datasets (the vehicle models and survey data) that feed into the calculation.
You said you worked with focus groups to get a clearer understanding of what was needed? What were some of the major problems that participants raised?
Feedback from the groups mentioned two major themes – speed, and hardware limitations. Existing software is hosted entirely on individual machines, stored on physical hardware. Unless you’ve invested in a high-speed processing machine, you’re constricted by processing power. Users were planning projects over overnight runs of assessments, adding days, sometimes weeks, to the timelines. These days, high-speed and cloud-based software is just expected, so why should gauging be any different and be left behind?
What kind of challenges did you experience that helped in developing D/Gauge Rift?
Most of the people we speak to have a pre-disposition about how gauging should be done, from the tools they are familiar with using. It is our responsibility as great software designers and innovative engineers to show them that a better solution exists to the problem.
When we are asked about new features or functionality, we really take the time to dig into what problem is looking to be solved. With any problem, there are hundreds of ways to solve it, and the risk with incumbent software is that people explain the solutions they need, not the problems they are trying to solve.
How did you work with Network Rail to get their software acceptance, what was their involvement in the development of the technology?
Delivering software that meets Network Rail’s requirements is all about collaboration. We had to ensure that the software had the functionality to perform the required tasks and ensure that the underlying mathematics matched the Network Rail ruleset. We have historically been through the acceptance process with our inhouse gauging tools, and so were familiar with some of the questions that were likely to be raised. Through our involvement with the Railway Group Standards (RGS) and having previously been through the acceptance process we were able to easily demonstrate that our software met all the industry needs for infrastructure gauging.
Separate to D/Gauge Rift, we have also won the contract to deliver clearances across the entire network in the ‘Network Clearance module. That module is powered by the same gauging engines that give Rift its exceptional performance.
How does D/Gauge Rift change the approach to gauging software?
D/Gauge Rift is a connected system. It’s connected to a network model of infrastructure survey data and vehicle models, streamlining the time it takes to setup assessments, and providing historical audit trails per site depending on available data. The system is cloud based, meaning it can be accessed on any PC and won’t slow down the hardware or crash the system. It’s also connected to Network Rail, allowing the industry to provide feedback and report data discrepancies. We’ve turned it into more than a standalone software for calculations, and more an ecosystem for clearance assessment.
What’s the single biggest benefit of using D/Gauge Rift?
For anyone who uses clearance assessment software, the biggest saving from D/Gauge Rift is time. This will save you buckets of time. It has loads of new features, interactive dashboards, and all fun stuff, but the biggest thing that Track and Infrastructure engineers will get their time back. In summary, D/Gauge Rift will be:
- Quick to get going.
- Quicker to set up.
- Quicker to assess.
- Quicker to iterate designs.
- Quicker to report and share findings.
- Quicker to make amendments.
- Quicker to find past projects.
In what ways was the process complicated before, and how does D/Gauge Rift simplify this?
Over the past 15 years, there has been a lot of changes in the gauging world. There is significantly more survey data thanks to the huge development in survey systems. There are more different types of trains running (with plenty more on the way), and the industry has overhauled every major standard, many of them twice.
The process of setting up an assessment has historically been complicated. It required a lot of knowledge of the subject matter (gauging) of the local rules (software configuration) and of the operational vehicles that needed to be considered.
Through our connected approach, by starting with the location we can take away the pains of setup, something from potentially hours of work to just a couple of minutes.
What does D/Gauge rift offer that other gauging software does not?
We’ve made something that is robust and reliable. It is something that superpowers our current need for gauging, and can scale up for the future of clearance assessment requirements.
Gauging software should let track designers run enough permutations to optimise design work. It should be fast enough that processing time shouldn’t part of your thinking.
We’ve also taken a new approach to licencing. Every user has an individual log in, which makes it much easier for audit and sharing purposes. Basic users can do everything in the software and log in from any internet connected machine. The gauging engine powers the actual clearance runs and pulls the computing power down from the cloud. It’s simple, effective, and fully scalable from small consultants to big corporates – we want to make it as easy as possible to get access to amazing software.
We’ve also taken a new approach to vehicle and survey data approval. Eliminating the back and forth for many engineers, vehicle data (with permissions levels), historic survey data and saved imports makes the software smarter and more intuitive. You can request new vehicles and amends to the data all within the software.
Finally, this is our bread and butter, so it’s very important to us. We take an agile approach to new features and have a very exciting roadmap ahead for the software, this is just the beginning!. We take an exceedingly active approach to development, and we move from concept, to ideas, to dev quite rapidly – to give the largest benefit to the end user.
This area used to be plagued with inaccurate modelling, poor data or out-of-date assumptions, why was that do you think and is it still the case?
I don’t believe this is a fair reflection of gauging, or the railway industry, at all. In mass, automated data collection (such as the National Gauging Database), there is inherently going to be some poor data. The key here is to be able to identify it quickly and for it to not disrupt your design process or resultant designs.
Likewise, we have over 250 permutations of passenger trains now in circulation, and there is a continual raft of design changes to meet the growing needs of the passengers (including accessibility, security, capacity etc). All these design changes do need to be fed back into the industry, and there is sometimes a bit of a delay in doing so. Let’s also not underestimate the timetabling challenge of understanding what is running where at any point in time. The current situation has demonstrated how flexible the industry can be in a crisis but tracking all those changes from a gauging viewpoint is a big task.
The best way forward is to collaborate with the stakeholders – Network Rail, OEM’s, Rolling Stock Owners, and TOCs. Its also about having reactive technical support with the engineering knowledge, so that when a question is raised about data, it can be challenged and actioned quickly.
What other stakeholders and operators have you worked with along the D/Gauge Rift development journey?
We had a fantastic group of beta customers, both old friends and new faces. Bonner Rail and their expert engineers were influential in helping to make informed design changes. End user experience and beta testing helped us to refine the vision and the practicality to create a refreshing new interface. Their ongoing support and feedback has been great.
We have worked with Network Rail’s gauging team for over a decade on numerous vehicle introduction projects. Understanding their pain points when it comes to gauging assessment and reporting has been key to designing reports that make the process of acceptance easier.
The Railway Industry Association were also key in helping to share the innovative technical side of the process. For us, this is more than a sales piece, rather a reflection of how we as an industry can use software and technology to eradicate hours of manual processing using automated systems. Being able to present at the Infrastructure Technical Interest Group was great, speaking on the principles that both D/Gauge Rift and Network Clearance were built upon, and how we’ve ‘Reinvented Gauging’.
What is the simplest way to answer the question, ‘why doesn’t the train fit’?
A quick question then… It’s quite easy to jump to the first and simplest conclusion that the train simply doesn’t fit. Modern rolling stock and freight loads are getting bigger (wider, longer), and more track friendly, meaning there is more movement in the suspension. If the train has never run there before, it may simply not fit. I would challenge that simply numerical analysis is not sufficient to draw that conclusion.
It could be some survey data discrepancies that cause isolated incidents. It is always good to review these and consider what has gone before. Could inaccurate data be responsible for false gauging issues? Raindrops, rogue track geometry and vegetation all provide data discrepancies that are worthy of review.
How does the assessment conditions match the operational conditions? The standards state a series of worst case scenarios to consider, but if the train condition, track condition or vehicle operation is far more favourable that might explain why a tight clearance scenario has never manifested into a more concerning situation. This is important to consider if the train design in question predates said standards.
A key takeaway is that gauging software provides an essential piece of the puzzle, and good gauging software provides some insight into the quality of the data used, but key to drawing conclusions is piecing that together with engineering judgement.
You worked in tyre performance analysis prior to joining D/Gauge, what similarities are there between the analysis of tyre data and gauging data?
I specifically worked in a motorsport setting, tailoring tyre designs to optimise track performance. Believe it or not there are similarities. Firstly, data is powerful, and you can never have enough. Ultimate lap time is nothing without context (consider whether the person who has the fastest lap time always wins!). The same could be said in gauging – if one survey says the train fits and another one says it doesn’t – which do you trust and why. The learning I brought into gauging was to never throw data away, and our survey database now goes back eight years, which helps us piece together what has changed, why, and what confidence we should have in it. Rift will also give that power to the track design community.
You joined D/Gauge almost eleven years ago, just a year after the company was founded, what has the journey been like?
When I joined D/Gauge it was really a research organisation where David was supporting a number of really good research initiatives. I came on board when the time was right to commercialise some of the technology and methods, and use them in anger on the Network. D/Gauge are now almost ten times the size in every aspect, and the journey from Engineer to Managing Director has been an interesting and rewarding one, be it with some challenges along the way.
I have had a great mentor in David and the Industry has been really supportive and onboard with our vision. We have a strong set of values which are important to remember when the organisation is busy. The one that really embodies how we operate is ‘Do it properly or not at all’ and the Rift software is no different.
We are hugely excited to be moving further into the software market at the same time as growing our established consultancy. As we move into a more cost conscience railway environment, I genuinely believe that better gauging will add huge value to major infrastructure projects, and now we can offer that in both a software (routine) or consultancy (bespoke) fashion.