Navigate the Predictive Maintenance, IoT and AI hype at InnoTrans 2018 — a practical checklist

Christian Sprauer
Railnova Blog
Published in
5 min readSep 17, 2018

At Innotrans 2018, manufacturers and IT vendors will demonstrate their shiny new IoT devices, digitisation programs and AI-enabled solutions.

As a railway operator and transit authority, the temptation is irresistible: you will be able to save millions on maintenance and downtime cost, be alerted before assets break down, and relax and watch your new real-time dashboards.

Reality and fiction

However, one of my biggest challenges in early talks with Clients is to explain the difference between reality and fiction, as decision makers are flooded with “IoT and AI can do everything” messages.

So here is my personal take on a checklist you can use when you visit a stand at InnoTrans. The checklist will help you to cut through the hype, to ask discerning questions, and to distinguish between what works today in railway, and what is fiction:

1. Is the vendor showing a live software demo or a Powerpoint presentation?

The only reason a sales person will still show you a powerpoint presentation in 2018 is that their software is not production ready, or that they don’t know how to use their own software. Be sure to ask for a demo to see if the solution fits your data and use case out of the box.

2. Is the vendor offering a free PoC (Proof of Concept) or a clear, paid-for, step forward?

A paid-for Proof of Concept is as much proof that the solution works in your context as it is proof that your organisation is ready for change. A paid-for PoC commits your internal ressources and obligates the vendor to deliver. Beware of free PoCs that may drag on for years due to lack of internal commitment, unclear objectives, and that leave the organisation at risk when decision times comes.

During the PoC, you should check how accurately anomalies are detected, how easily you can configure new alerts and new data sources, and how easily data and alerts can be consumed by users and other systems.

3. Is the vendor trying to add requirements to your technical specification?

You may be facing a software consultancy business that generates revenue from client’s “wants” and “change requests”, with little functionality out of the box.

Check how the vendor plans on achieving your use case — via custom developments or via product configuration? A good trick is to ask the vendor for the typical revenue structure of a contract and to check for licence revenues. A mix of 70% software licences (justified by a strong product and years invested in R&D) and 30% custom development (no more) is healthy and very likely to provide value out of the box to your organisation.

4. Does the vendor technology leverage proven AI techniques?

Scanned invoice document recognition now works accurately thanks to advances in deep learning, but automatic driving is still a far reality. When it comes to predictive maintenance in Railway, you should be able to understand how the proposed technology works (even if you are not a techy person) and how accurately it works.

Sometimes a boring physical model such as « the temperature is now 2x standard deviation greater than the moving average » , validated on your fleet historic dataset, filtered for all corner cases and deployed on the real-time fleet data stream can already do miracles.

There are plenty of resources available online to understand the basics of AI, and I’d recommend documenting yourself. You can start by watching this general video on AI :

5. Does the vendor check that the data covers your use case?

Some vendors will unscrupulously promise you that machine learning will infer abnormal events from unrelated data, by looking at the context, weather, utilisation patterns. Although this can be true in some cases, when it comes to our physical world of tear and wear, and complex failure modes, we have learned that special attention needs to be paid to the data sources.

At Railnova we have failed at something as “simple” as a low-battery alert: we were missing the battery current and found out that the battery voltage was not sufficient to predict the battery state of charge for a certain battery type.

So we went on and spent 2 month featurising battery voltage, maintenance textual data, battery replacement data, weather, temperature, humidity conditions, utilisation patterns, the duration the train was parked before a battery failure, the number of engine starts before a failure, the location, the day of week and time of day, and added another 1000 data features with automatic time series featurisation. We then applied XGBoost (an advanced machine learning model) on our labelled and featurised data set, only to find out that we couldn’t predict low battery failures accurately. We were simply missing the battery current information which prevented us from predicting when this specific battery type was discharged.

6. Is the vendor’s solution built on the promise of “collect all data now, find patterns later”?

This is by far the greatest mistake I see CEO’s make when selecting an AI or IoT solution. Our experience at Railnova shows that you almost always need to iterate several times between the data collection technique (by adapting sampling rates, unit conversion, adding new signals from the MVB bus, adding new sensors,…) and the pattern recognition technique, in order to deliver proper alert triggers. Collect data now for your use case now and fine tune it. When new data is needed for new use cases, remote update the software of your train-mounted device to obtain such new data.

Remote update of Railnova’s edge rule engine to enable new cases, (ask us for a demo) !

7. Does the Vendor have a clear approach to safety and IT security for remote device software update?

Retrofitting trains with hardware devices that support remote software updates can be challenging from both railway safety and IT security perspectives. However, frequent remote software updates will be necessary to achieve your use case. If the vendor solution is SIL4 and integrated into the trains signalling system, such software updates are going to be quasi-impossible. Look for a solution that offers safe, ISA approved, passive reading of train bus coupled with a clear IT security policy listing out which staff members can access the device management platform to remotely update the device software.

If you enjoyed reading this post, pass by our stand at InnoTrans (Hall 6.1 / Stand 210) to discuss your use case or go to https://blog.railnova.eu to stay in touch with our latest product news. You can also subscribe to our monthly newsletter here .

About me: I am Founder and CEO of Railnova, a real-time remote monitoring and fleet management solution for railway rolling stock. I founded Railnova in 2010 after being responsible for 400 locomotives in 12 countries at a leasing company.

--

--

Christian Sprauer
Railnova Blog

Entrepreneur in Railway, CEO of @railnova. Make things work, make happy customers, build leading teams. Occasional python programmer, mountainbiker, father.