“In the past, we as a component supplier have been confronted more with classic software development and user development – less with cloud computing. It’s always a good idea to bring external expertise into the company and initially set up the project with them.” – Maximilian Stadlbauer, Frauscher Sensor Technology
In this podcast episode, IoT provider All for One or its subsidiary CDE Engineering and IoT user Frauscher Sensor Technology are guests. The podcast is about optimizing the performance and reliability of railroad lines with the help of an IoT diagnostic system that collects sensor data, analyzes it and makes it available for evaluation.
Episode 57 at a glance (and click):
[09:49] Challenges, potentials and status quo – This is what the use case looks like in practice
[15:06] Solutions, offerings and services – A look at the technologies used
[26:59] Results, Business Models and Best Practices – How Success is Measured
[30:10] Transferability, Scaling, and Next Steps – Here’s how you can use this use case.
Podcast episode summary
We take it for granted that the train we board will take us safely to our destination. But behind this seemingly self-evident fact lies complex technology – like the signal components from Frauscher Sensor Technology. Frauscher is a specialist in the field of railroad operation, and here in particular for the so-called axle counters and wheel sensors.
The All for One Group is one of the leading digitization partners in the German-speaking SME sector. In this podcast episode, Madeleine Mickeleit talks to All for One and its subsidiary CDE Engineering about their collaboration with Frauscher. CDE is an expert in smart products, SAP-related, MES-light, smart factory products, but also predictive maintenance. Frauscher Sensor Technology is one of its 2,500 customers from the DACH region. In this episode, the two partners show how sensor data and components from Frauscher are connected to the cloud and how digital networking integrates intelligently and smoothly into existing business processes. Episode number 57 of the IoT Use Case Podcast deals with exactly how this also optimizes maintenance work, makes trains more punctual, and what added value the All for One Group offers Frauscher.
The podcast guests:
- Andreas Lehner (Head of Web Development, CDE GmbH)
- Maximilian Stadlbauer (Product Management, Frauscher Sensor Technology)
Podcast interview
Andreas, would you like to introduce yourself very briefly and tell us what exactly you do at All for One? Or rather, you are at the subsidiary CDE.
Andreas
I am Andreas Lehner. I am responsible for the Web App and Data Science area in the All-for-One subsidiary CDE. We develop software and IoT solutions to be able to improve our customers’ products. Normally, these are all individual developments. We accompany the customer from the idea, through the implementation to the operation of their solution. That’s where our holistic approach is particularly important. This means from the sensor connection, to the edge, to the interface for connectivity to the cloud or other servers, including the user interface or the corresponding application.
Who are your typical customers and partners here?
Andreas
Our customers are usually medium-sized companies from the industrial environment. They are mostly product manufacturers – examples include STABILO, ekey, Plasser & Theurer – but also operate in the medical products environment, where correspondingly high quality is required.
Maximilian, would you like to introduce yourself?
Maximilian
My name is Maximilian Stadlbauer. I have been with Frauscher for five years and am responsible for the software products area with a focus on diagnostics. Frauscher has now been in the axle counting business for over 30 years, something like 600 employees, a medium-sized company in Upper Austria on the border with Bavaria. We are a component supplier for the railroad industry, for safe railroad operation.
Axle counter business – Axle counters: Where exactly are they used? Directly on the rail?
Maximilian
Exactly. An axle counter is basically a sensor that detects the passage of a train, or a wheel. They are mounted on the tracks. It’s not like the classic car ride where you drive on sight and see everything in front of you. Instead, a locomotive driver must be able to rely on the signaling technology, i.e. traffic signals, etc., as to whether he is allowed to enter this next section of track. These tracks are divided into so-called clearance sections, or line sections. The limits of these sections are monitored by our wheel sensors, which then results in a so-called clearance message. This means that the operator or train driver then knows that there is no train in this section and that the next train may enter this section and pass through the next passage.
Now it’s a matter of using your sensor technology and the track and data, respectively. What is your vision here in this regard? What drives rail transport or the industry you are in?
Maximilian
Great topic, exactly. Industry 4.0, or IoT, is on everyone’s lips anyway. We have also thought about how we can support our operators and customers in this respect. Systems are continuously becoming more complex, which means you need a lot of know-how to maintain a system and understand what the system is doing et cetera. That’s where we said we could step in – who understands the product better than we do? How can we create transparency for the customer, make the system more transparent? There it goes in this direction, the diagnosis, especially in maintenance to support the customer. Helping them identify problems earlier. You have to imagine, first of all, that the rail operator wants safe traffic on the tracks and also high availability. This means that maintenance intervals are getting shorter and shorter; maintenance windows are getting shorter and shorter. That means he has to try to get through his tasks faster – usually in night shifts et cetera. To that end, with appropriate diagnostics, or a bit in the direction of predictive maintenance, we can help the customer work out their points, their to-do’s, BEFORE problems arise. Until now, it’s been more classic with maintenance intervals and manual work. This is where we could support the customer with IoT, or IIoT in this case.
The bottom line is also about the delays we all know about, and also about the issue of safety. You have to make sure no one is on the track. And that availability – that you keep those time windows as small as possible to get delays out of the way at best, right?
Maximilian
Exactly. Achieve high throughput rates. Especially in urban areas, when you think about rush hour, subways, etc., a lot of people want to get from A to B quickly in a small time window. Especially in these areas it is necessary that then no disturbance occurs and the railroad operation is not disturbed. Of course, safety is a top priority: everyone wants to arrive safely at their destination.
To break it down a bit – who are your customers, that is, besides the railroads, also the subways?
Maximilian
We have two types of customers. One is the railroad operators, such as in industry, mining et cetera. They also have suitable tracks. This safety aspect is not quite so important. Of course ALSO important, but not quite the same as in an urban operation where I have a subway operation. And the other clientele are the so-called integrators, such as Siemens – there are several major players here – who install the signaling technology for rail operators, in principle working out a project. There we are a small but not very insignificant component to ensure this signaling technology and to guarantee the railroad operation.
Challenges, potentials and status quo - This is what the use case looks like in practice [09:49]
If I imagine a maintenance technician and also the daily job: What does it look like on site and what are his tasks? Is that classic, that he looks at the signaling and does the maintenance manually?
Maximilian
Difficult question. After all, the operators have a great many components; we are just one of them. This also includes light signals, track switches, etc. The railroad operation overhead lines, power supply. There are very, very many components that the rail operator has to assess and maintain. We also have our specifications here on how our components are to be maintained. That’s about monthly or annual inspections, it depends a little bit.
Our customers clock these services into their maintenance intervals, and then the wheel sensor is inspected during the maintenance windows. Also check for any defects, mechanical defects; if the wheel sensor is still mounted. After all, we are in a relatively harsh environment. We are positioned worldwide, which means we have very hot as well as very cold temperatures. Moisture is an issue, flooding. Or even vibrations. Especially on the track, you know it: when a train passes somewhere, every now and then you hear such a rattling, depending on the maintenance of the tracks. Of course, this also affects our sensors. Accordingly, the sensor must be maintained occasionally, and this is done in these maintenance windows.
That is, I have disturbances somewhere that occur on a section of track like this, perhaps due to external factors. Times come up – you said the technician has to do it in certain maintenance cycles, has little time. How is this maintenance work done today? Does this sensor already report this itself? How does that work today, that is, without the digital solution that you built together; that is, the classic maintenance business in practice.
Maximilian
Currently, the maintenance looks like this: After all, there is already a historical diagnostic system on site that records data. Where to retrieve the data to see what happened – for example, in the event of a malfunction or failure? What was the deciding factor in how this disruption came about? There you can understand what happened. Of course, you still need the appropriate expertise for this. It is a very axle counter specific issue. To do this, you also have to get to grips with the subject matter a little. That would be the point where we would like to step in. That we support the customer here, that he no longer needs all this expert knowledge in detail, but that we can help him here with a system and can show him the corresponding steps that have to be taken a little better.
In other words, you have to think of it as your sensor reporting this data in a diagnostic system at a certain threshold – whether it’s a vibration or whatever trigger. And the next step is to make this data even more available, and to do it more proactively?
Maximilian
Proactive, exactly. Think of it this way: there are two levels. One is a so-called warning, which means that the sensor has a problem, but it does not yet jeopardize operation. The other is the malfunction, that’s sort of the worst case for the operator, because that means someone has to go out immediately and somehow fix that malfunction. This restricts rail operations because they cannot then use the section in its entirety. In principle, this means that you have to look at the diagnostic data, deal with the subject – and then usually under time pressure. You want to get back into regular operation quickly, and we are also in the safe area. Safety partly means that you have to make so-called free runs, which means that a train has to pass through at reduced speed et cetera. Each operator has its own set of rules on how to make its rail operations safe. This is, of course, associated with considerable effort. It would now make sense to actively check these warnings, which the customer currently has to check or search for manually, and to make them transparent to the customer with proactive messages, etc., so that the customer is aware of the issue or the malfunction or warning and can clock this into the maintenance windows accordingly.
Solutions, offerings and services - A look at the technologies used [15:06]
If I understand correctly, this is exactly the project where you say, so far it’s been the alerts that have come up in the diagnostic system – and the next step is to proactively address that issue with All for One and take that to the next level. How exactly do you work together here? Who does what in this solution?
Maximilian
In this solution, we have a common interface, that is, a protocol where we forward the data from our inventory diagnostic system to a higher-level system. The current diagnostic system is decentralized and distributed over several sections. All these components are to supply data to a central system, via this interface to the higher-level system, where they are to be evaluated.
That is, you have your sensor, then this intermediate system, and then this parent layer. Andreas, I would like to understand this in more detail. How exactly does this manual – these processes that we want to address proactively – get into the digital?
Andreas
As Max said, the diagnostic system as it exists now is a decentralized system. This means that you also need several such diagnostic devices for a correspondingly large project in the rail sector. The goal of the software solution we have developed brings exactly this information from all the different diagnostic devices to ONE parent diagnostic device. This means that from this moment on, the entire project can be monitored from one system. This is the basis for our development, where we can then analyze and evaluate this data in the network in order to provide the customer with targeted information.
One step deeper into architecture, how do I have to imagine that? I have various diagnostic systems running individually somewhere out there with customers – metro operators, other rail operators. These should all be lifted centrally into a higher-level system to proactively address the issue? Can you tell us a little bit about what the architecture looks like for that?
Andreas
At the beginning of the project, we thought about how the architecture should look in detail and decided relatively quickly that we wanted to instantiate a microservice architecture in this case. That means you develop different services that all do a specific task in that system. For one thing, it starts with having a service where you can retrieve this data from the diagnostic equipment. This means that this interface is a network interface and there is a certain protocol. We have a service that understands this protocol and can process it and thus collect the diagnostic data in the devices. Since the project was set up from the outset in such a way that it might be possible to move it to the cloud at some point in the future – it is currently running on a local server at the customer’s site – we decided on this microservice architecture so that we can instantiate several of these services in parallel in the future and theoretically access the data from these diagnostic devices worldwide. From this point we have a database where we store this data. In detail, we also use caching databases in the background to reduce the load on the actual database. That is, this is a multi-level system where we can bring the data into our main database. From there, the data is analyzed using a proprietary data analysis service. This is about this proactive information that we provide to customers. That is, what warnings, what errors are in the system? What maintenance work is also due? Everything we have already heard in the context here. We then process this information accordingly via an API and have also developed a frontend, a web-based user interface, where you can view this information. This then includes user management, settings; certain pages where you can look at specific aspects about the system, such as its health.
Maximilian, can you explain this a bit more from a practical point of view? Andreas says you have an API, different databases. What data, sensor data, is coming in? And what is the output? Do you have a dashboard where people can log in, which is there for your customers?
Maximilian
There is a wide variety of data. Of the entire axle counting system in general, there is redundancy information et cetera. An important value, for example, is the wheel sensor current, which is important for our sensors, which we can also monitor with it, which is also an indication of whether maintenance is due again. Or a sensor adjustment. You have to adjust our sensors. Not calibrate, but making an adjustment. For example, that would be information that we can provide to the customer, with the diagnostic dashboard. There is then a landing page of sorts where the user can log in to view the data. These are prepared graphically, so you no longer have to plow through the historical data, but you have the prepared information in the dashboard and can call up all the data across the entire system.
That is, I have to imagine that I have a dashboard in front of me, where I have a few colorful graphs and can see, for example, the diagnosis of the wheel sensor current – there are certain threshold values that you have stored somewhere, and if they are exceeded, the output is displayed there. That means I don’t have to go through the data, I can see in the dashboard in one fell swoop, what was the error?
Maximilian
Exactly.
Andreas, you said you come from the field of Web App, Data Science, you are the experts there. But to someone hearing this for the first time, it sounds like a huge field. Maximilian, what kind of knowledge did you need for this? Have you had all this? You’re from the field, but what does it take to get started with a topic like this?
Maximilian
Especially for these microservices, or preparing for cloud or moving the application to the cloud, you need appropriate knowledge, of course. We didn’t have that in-house at the time. That was also the reason why we then looked around and came across CDE. That’s actually when the partnership started.
How did you work together on that? Maybe also looking back; you’ve been in the project for a while now.
Andreas
Exactly. The project began in such a way that we held a joint workshop in order to understand the system. In this case, it was a three-day workshop where we really got to know the specialties of axle counting systems in part. So really too, how do axle counters work technically? So that we can set up an appropriate system and have the background understanding. Based on that, we took a SCRUM-based approach, filled the backlog in this workshop and described the first tasks where we defined our first goal. The Minimum Viable Product. Where we said, with this we can sort of go to our first customer. We then got that to work. Implementing this interface that we have data available at all, and then displaying it at least in a list. Just to get started, completely without a dashboard. To see that this higher-level diagnostic system is functioning appropriately.
So to ask the customer in the first place, do you need it one way or another? So having a little bit of a conversation with him about exactly what that’s going to look like, right?
Andreas
Exactly, and also in the context the user stories defined to define from the user’s views, what does the user need for his work? How can he use this system properly? Of course, with very strong support from Frauscher, who of course know who their users are in the system in the first place.
Sure, that’s a maintenance technician, for example; he has a login and then only sees the issues that are relevant to him, right?
Andreas
Right, exactly, for example.
Maximilian, to the practice. Many out there may be working on similar projects. In summary, what components did you need from All for One? Can you say there, I need one, two, three … can you summarize it that easily?
Maximilian
In this particular case, we needed the software service. So the know-how of how to build cloud computing, or an application that needs to be cloud-ready. How to set up the architecture. What issues there are to consider – be it bandwidths et cetera. You definitely need know-how, and it’s not bad to have someone who knows the ropes and can support you. Because we as a component supplier are more classical software development and user development, and have been little confronted with cloud computing in the past. It’s always a good idea to bring external expertise into the company and initially set up the project with them – which is what happened in our case.
Andreas has already mentioned that there are various database structures behind this, where you have brought together your competencies. Then you probably only need a PC from the customer where the whole thing runs – or rather, it’s not in the public cloud but hosted by the customer – and your components, of course, which are used where the data is generated in the first place. To sum up; could you say that?
Andreas
Exactly.
Results, Business Models and Best Practices - How Success is Measured [26:59]
Best practices – a lot of people always ask me, “Madeleine, so can your partners share some best practices and pitfalls from the field?” And the other thing is, at the end of the day, it’s really about a business case. So you on the Frauscher side are also going down a path where you say, up to now the components were installed somewhere … now we’re bringing in new intelligence – you’re the manufacturer and of course you know your components and could make this data usable, also for others. That is also a new business model somewhere, perhaps, or also a business case that you have set up. Maximilian, what does the business case look like for you? Where do you want to go with it?
Maximilian
One issue is that we can re-establish contact with our customer. After all, if you’re a component supplier, you supply the components, and “that’s it” in the end. You might provide support where you can during the project phase or in lifecycle management. And with this system, the aspiration would be to work closer together and be closer to the customer again. Also can better gain the needs of the customer and support him in his daily work. That would theoretically be a basis for a new business model, yes.
Where the journey actually goes remains to be seen. As we discussed at the beginning, the systems are now running at the operator’s site – so they are not yet in the cloud. That would be the next conceivable step. However, you have to be very careful here. We live in a time when cybersecurity plays a huge role. Particularly for rail operators, where passenger transport, freight transport and availability issues are involved, cybersecurity is a very big issue; we must definitely address this and take measures to ensure that nothing can happen that could somehow jeopardize rail operations. There we are in preparation.
Yeah, sure, security, huge topic. And the other thing is, of course, the business potential then comes in the future. If you look at, the issue of light signals, overhead lines, those are then externals – even OTHER players that play into it. If you take this to the next level and say that you are perhaps also moving in the direction of the cloud, then in the future – the buzzword is smart city – you can bring together the most diverse trades and also leverage completely different potentials. By making the trades talk to each other. That is probably also something else, which is perhaps chance of the whole thing?
Maximilian
There are certainly a lot of areas where you can push the whole thing even further, yes. Quite an exciting topic, in any case. Just the networking of various components; enrichment with other data et cetera. There are still many areas of application.
Transferability, Scaling, and Next Steps - Here's how you can use this use case. [30:10]
Andreas, you have a wide variety of customers with whom you work. Do you also see similar use cases, projects also with others who are perhaps also already thinking this far into the future?
Andreas
I must say that IoT projects are mostly different. However, we already have experience and knowledge of how to implement such projects in different areas. Basically, this tool of the trade that you need for such implementations always looks similar. With these customer workshops that we have in the area, we want to show the customers what is all possible, so what is there? And what does that look like for the customer in concrete terms? So they are very individualized solutions, but there is a common base from which you can start and from which you can translate that to any other use case in IoT.
How does the cooperation with Frauscher continue? What else do you have planned?
Andreas
The project itself, for the higher-ranking diagnostic system, we have now successfully completed. We have now been able to enable the customer to continue with this solution himself. This means that no further project is now happening immediately in this area. However, there is still cooperation in the area of Smart Factory and also S/4HANA, SAP implementation.
After all, that’s exactly the goal: you enable the customer. Maximilian, you have expanded your competencies over time. This is also a process that you go through and walk together up to a certain point, and finally expand yourself with further competencies that you have in-house. If I want to get in touch with you guys, that is, anything about specific components – what’s the next step with you guys? Can you just call and ask?
Maximilian
There are many options. We are on social media platforms. We have a web page where you can contact us. We are also present at trade fairs. There are several channels on how to contact us. So, there are no limits and we are happy to receive any request.
Can you just take a look at a wheel sensor or your components in detail?
Maximilian
Exactly. I would recommend going to a trade fair stand. There are special railroad fairs where we are always represented. There are, of course, online screenings. We now also do online training. Due to Corona we offer trainings. Or also in the telephone calls with the customer that one shows times such a system, from training center out, with Webcams et cetera. So there are ALWAYS some ways to bring the system closer to the customer and make it a little more transparent. Because axle counting is of course a very separate topic, I’ll say now.
Andreas, if I am also a component builder or have a similar project going on. How do I reach you from All for One or CDE?
Andreas
The best way to reach us is actually via the web page. So we also have a homepage. We also use social media channels. And basically also gladly directly by e-mail.
Very good. I would put in the show notes your contacts on LinkedIn, and the others as well. Then you can make contact and discuss one or the other project.
Andreas
Perhaps a small piece of advice that can be given along the way: If you have planned such an IIoT project or are planning to do so – don’t spend a long time planning what you can do with which data. Just get started with a prototype and gain insights. You will notice that the journey may be slightly different than planned and you will gain a lot of insights that you might not have gained otherwise and that you might not have thought of. We can only recommend this to everyone.
You probably learn a lot along the way, too, don’t you?
Andreas
Don’t be afraid of the data, just always put it in and analyze it.
Thank you very much!
