In which a large railway uses FME Server to build a real-time message broadcasting service to handle 3,000,000 messages per day – and yes, that is 125,000 Messages Per Hour.
Maybe it’s a side effect of spending time and care to bring you interesting and valuable stories of how FME users are innovating around the world, or perhaps it’s just being a grown-up in the internet age – but in either case, “clickbait” headlines send my blood pressure through the roof.
But when I received an email a couple of weeks ago about what a certain customer was up to, all I could think was:
“You won’t believe what this guy did with FME Server.”
Usually when we bring you stories here on the blog, we are able to share who it is. This time, circumstances have prevented us from being able to do that – but the people behind this project have graciously offered to share the story without credit – that’s how excited they are about what they’re doing.
And now, studiously avoiding “one-weird-tips” and “this-will-shock-you-s”, I shall tell you all about it.
A Product Retirement Conundrum
Railways are big operations. Consider the assets – not just thousands and thousands of miles of linear rail, but locomotives, cars, inspection vehicles, hi-rails, test cars, maintenance and security… it’s simply a lot of stuff. And most of it has a spatial component. So it’s not surprising that Safe has many railway customers using FME to assist.
One of them had been relying on an off-the-shelf solution for pushing real-time messages around for some years when the news came in that the product would be retired shortly. An evaluation of the replacement from the same vendor was done by the architecture team, and found that it just wasn’t good enough to meet their critical needs.
Buy, Build, or a Bit of Both?
And so began the usual process of evaluating alternatives. Some were simply too expensive, some were still vaporware and promises. One option was to code it in-house – which would have involved 18 months of development time.
The GIS team, already adept in the art of using FME to integrate just about everything, had a different idea. Why not build a new message broadcaster with FME Server?
And so they did.
How It Works
The FME Broadcaster (as it’s been dubbed there) resides on two servers, each with an FME Server core and four engines. They both run a perpetual workspace, turning it into, in their words, “a massive message streaming engine.”
There are three primary components to the workspace, handling the message flow –
- a JMS (Java Messaging Service) Receiver, which listens to the 20 planned incoming message queues;
- a SQLExecutor, which passes messages over to Oracle for insertion; and
- a WebSocketSender, which maintains a persistent connection to the end user GUI to provide near real-time updates.
Along the way, messages are being reformatted, parsing the source data XML and transforming to JSON, the format that the WebSocketSender is serving up. The ability to handle all of this with just one workspace (and not twenty!) is due to a very recent enhancement rolled out in FME 2014 SP4, enabling the JMSReceiver to listen to multiple queues.
First Up: Ultrasonic Track Testing Vehicles
The first stage to go live is the UI for Ultrasonic Track Testing (UTT) vehicles. These trucks inspect the tracks daily with ultrasound, looking for potential points of failure, and can cover hundreds of thousands of miles of track each year.
Through this system, they can monitor the trucks’ movements live, and see their history as a breadcrumb trail. They’ve also enriched the data – as is common in railway data management, a linear referencing system is used, and so the points are converted to LRS for comparison with milepoint markers.
On the more conventional GIS side of data analysis, polygons for administrative and other boundaries are overlaid for various purposes. And they can even account for when the operators are on a break, away from the track, and mask the irrelevant data from that period.
Scaling Up – and Out
The UTT vehicles generate around 1,000 messages per day, with five attributes. Next up: this FME Server-based system has to be ready and able to handle locomotives, security patrols, Hi-Rails, inspection vehicles, supervisors… their fleet of 4,000 or so vehicles will rapidly add up to a message load of 3,000,000 per day.
The architecture is designed for capacity. By isolating the servers, and having them act in parallel on the same task as they pick messages and route them accordingly, the system will expand – more cores will handle more messages. They’re metaphorically just widening the pipe. The same workspace, running on more and more cores, intelligently listens and allocates.
Even as the messages become more complex – for example, locomotive messages include data on brake pressures, fuel levels, and more – horizontal expansion of the system will simply handle it. And rather than designate a primary and fail-over system, message allocation will be balanced across remaining resources in case of a system failure.
And so, when the ultimate expansion comes – that of having a GPS sensor on every single rail car—the system will look pretty much like it does today. With a LOT more servers.
Vehicle tracking and message handling aren’t brand-new technologies. But here’s the point: Railways are operations whose assets are very location-oriented, and FME is already key to enabling a multitude of data requirements within the industry. And at this customer, they’ve extended both the utility of the product and the value of in-house expertise to an entirely new plateau.
And did I mention 3,000,000 messages per day? With FME Server?
And so thanks to the team who built this for sharing their ideas – which they described as “wicked!” architecture. I must agree – and I hope this gives you some ideas of your own of how FME might – just might – be able to do more for you than you ever imagined.
Want to learn more? Didn’t think I could resist adding just a couple more clickbait references? You were right.
This One Weird Tip will change your approach to data: Moving Data over the Web: AJAX vs. WebSockets vs. Webhooks
“Before and After” data that will blow your mind: Real-Time Data Transformation with FME
Kris MajuryKris is a content developer at Safe Software who concentrates on creating documentation for FME transformers. Kris works remotely from the wonderful Gulf Islands off the coast of British Columbia.