Cutting edge: assessing the potential of edge computing in transport

Firstly, let’s talk about edge computing – what is it exactly, and what are the benefits?

Edge computing takes computation power and data storage and places it in the environment in which it is needed, as close to the action as possible. Lots of services make use of centralised computing in the cloud, but companies are increasingly looking away from the cloud to edge computing, to provide a balance between bandwidth, security, latency and cost at the edge verses big data analytics in the cloud. In the last 10 years, a lot of companies have moved their infrastructure costs over to the cloud – even from a personal point of view, most of us have a Dropbox or iCloud account. These companies have three main reasons for wanting to move away from cloud.

One is cost: cloud technology itself might be cheaper now, but if you’re storing a lot of data then the cost of bandwidth to send it to the cloud could be huge, and you might suffer from congestion in uploading and in certain use cases you may not have a reliable or a throttled backhaul. Many companies are now storing data in the cloud without necessarily having a game plan that utilises this knowledge and feeds the results back into the business processes. The second reason is security; do these companies actually have a grasp of where their data is going and what’s happening with it? More often than not, the captured data is sent back to a third-party cloud storage provider which could be located anywhere – and then what? Finally, there’s the IoT perspective where latency is a major consideration; what happens when something happens that requires an instant response? If you’re sending that enquiry back to the cloud to be processed and then need to send a response back, that probably isn’t going to be fast enough.

What is the use case for edge computing in transport?

As I said, we’re looking at edge computers being as close to the end point as possible – as close to where the action’s happening. A moving train is actually a really good use case, because even if you get on a smart train today, it’s only as smart as when it’s connected to the internet. Even on the latest trains you’re likely to hit a black spot with the current connectivity.

Edge computing puts the network on the train. With two edge servers in each carriage, you form what can be considered a ‘wireless daisy chain’ network. This gives you coverage inside the carriage, which is the linked to the next carriage and the next, thereby providing a standalone wireless network running the entire length of the train. This network can now operate with no backhaul connection to the cloud needed, allowing your applications, which are currently running up in the cloud, to now be deployed locally at the edge. These apps, which are running as docker containers on a Linux based computing hub can be very diverse and cover many different business needs. There is a lot of potential for edge computing in this industry, lots of new use cases and business cases, and that’s where I think it gets really interesting.

One example use case is predictive maintenance. A standard Bluetooth sensor can communicate track or carriage vibrations to an edge computer, and then using local processing for machine learning, you can send back to the cloud summary information if needed. A lot of trains currently use cellular sensors that just send data back to the cloud fairly blindly. There’s a cost involved in that. By moving to Bluetooth sensors, you’ll capture that data on the edge, the idea being that once the train has finished its journeys for the day, it’ll plug into the LAN and then send the data on, which will also allow the machine learning algorithm model to evolve over time.

Are there benefits for the passenger as well?

Absolutely. We’ve been working with a UK ROSCO, who, like a lot of companies, have lots of ideas about what they’d like to do, but without that guarantee of connectivity, a lot of those ideas wouldn’t really come to fruition. They had a good list of applications that were split between IoT productivity, passenger experience and operations

When a passenger boards a train with their bike or their luggage, they’re mostly unable to sit nearby to keep an eye on it. The concept here is that if you have a smart ticket on your phone, when you get to the luggage rack or bike compartment, there’ll be a QR code or barcode to scan which will enable you to get a  direct link to an IP camera so you can view activity detected from anywhere along the length of the train directly on your phone . It provides the passenger with peace of mind, but also represents potential cost savings for the operator. The problem with some train CCTV now is that all of the intelligence is in the camera. This can be very expensive to keep up to date, as new models are released regularly and may even require new fixings. By using a low-cost IP-access camera, all of the intelligence is now running as a containerised application on the edge computer and can be easily updated as new features are developed.

Other potential applications on trains is for communication and announcements. If two people were to have a conversation over FaceTime or Whatsapp, even sat right next to each other, that conversation would need to be going through a cloud somewhere. With a localised, secure network, the conversation would never leave the confines of the train carriage and is not reliant on a cloud connection. This would allow the guard to have a conversation, send texts or even have a video call directly with the driver and other staff using just their smartphones.

The nature of local network allows for greater pinpointing and specificity meaning the guard is no longer tied to making announcements from a single designated point in a carriage but can now make an announcement from their smartphone and choose if the message needs to go to all the carriages, just one carriage, or just one set of speakers next to seats in a certain carriage.

These use cases would help staff be a lot smarter with how they communicate with each other and their passengers.

In theory, you could have one mesh on the train and another in the train station, so that as the train pulls up to the station, the two meshes join together, enabling communication between the guard, the driver and staff on the platform.

Edge computing obviously has huge potential, but what’s your view on the development cycle in this industry and how it adopts new technologies?

I’d compare it to what the automotive industry was like 10 years ago. For suppliers, it took time to get anywhere near an automotive design room, but once they were in, they were in for a couple of generations. That has changed a lot now with the advent of connected and autonomous vehicles   as we’re seeing technology acceptance accelerating rapidly, and I think that rail could be set to follow, driven particularly by consumer demand.

There’s a clear trend towards more agile and disruptive companies becoming part of the industry, and they’re putting the work in to make sure they’re meeting specification and complying with regulation.

Over the last 20 years, technology has disrupted everything from print and film, to music. Some have handled disruption well, others have gone under, and the transport industry cannot afford to be stubborn and persist with the same ideas it’s been peddling for the last 30 years for the next 30. Edge computing offers the opportunity to underlay smart cities and smart transport networks with the same network architecture – the level of interoperability that could provide can only be a good thing.