Toyota Material Handling Europe’s team of developers (then, just a duo) started building applications for networked forklift trucks over a decade ago. The offering was initially simple – if effective – and somewhat experimental. A small but growing number of customers wanted to check usage rates and locations for their fleets of forklifts and, aiming to please, Toyota’s team set about building the infrastructure and back-end to support fleets of networked forklift trucks.
The early back-end was built around an on-premises stack, with the application data sitting in a SQL database – it was unclear how fast customer demand was going to scale – while a front-end application let customers check in on their fleets via a smartphone or desktop app.
Materials handling is automating and digitalising fast, for all the associations the sector may have with manual heavy lifting, and demand was stronger than the duo anticipated.
The challenge of optimising warehouse space, reducing costs, avoiding damage and working with demanding and increasingly digital-first customers means there’s little scope for sitting still in the industry, with demand for data on forklift use, the ability to geo-restrict forklift truck activity, and more all increasingly popular across Toyota Material Handling’s sprawling customer base. (The company now has an “internet of forklifts” of over 130,000 vehicles).
As customer requests for new application features poured in (the company’s networked forklifts are now at work in factories handling materials ranging from tyres to cheese), stress marks emerged in how the architecture was built.
As one of the developers, Kristofer Spong puts it to Computer Business Review: “We had some challenging times in autumn 2015 and so we started to think about an alternative architecture. It was a bit early for us at the time to think about cloud and we didn’t want to build something too big until we knew how strong interest would be.
“We were a small team, working for a forklift company: it was just the two of us as developers, balancing challenges with on-premises infrastructure and trying to implement new features on the demand of our increasing customers, but we knew we needed changes.”
Content from our partners
Networked forklift trucks: test, deploy, (self)drive…
The team – in an increasingly common trajectory across industries – started to think about breaking their “monolith” down into microservices and swapping their on-premises SQL database for something more flexible – ultimately settling on MongoDB Atlas, a cloud-based managed database using the non-relational MongoDB system, in this case running on Microsoft’s Azure.
As Roger Wahlström, a senior system architect on the project puts it: “We had this monolithic system where you build one system for everything; a single database… But we saw on the horizon that demand is growing, a lot of devices were joining. We realised that we need to work parallel, rather than wait for each other, so we started thinking both about how we store data, and how we build features; and started exploring a microservices architecture as a result.
“The project was complex in 2015, but we had knowledge of the code base, we were together in the same location working together every day; we didn’t see problems until we really started to grow significantly. At that point the ability to break things apart became crucial; and to scale out the logic, IT resources, and team working with us, to scale out the competency.”
In monolithic architectures, the majority of application functionality lives within a single service which is tested, deployed, and scaled as one unit. Microservices, by contrast, comprise small, single-purpose processes that can be combined to build applications; they can be developed independently, and be decoupled and recombined in a range of ways. That SQL database (by 2015, three of them) at the heart of this monolith, was also a problem.
SQL databases, for those unfamiliar, store related information in separate tables, linked through the use of foreign keys and joins; a fast, powerful but rigid approach that means changes in schema to support new features in an application require a migration procedure that can take the database offline or significantly reduce application performance.
As Toyota’s Kristofer Spong puts it: “When you’re working with IoT, you never stop developing; you don’t know what new demand is going to look like.
“SQL is really structured, you store the same data all the time. If you know exactly what you’re going to do, you can easily work out what data you need to store for that feature or application. But that becomes very rigid and hard to change later on. One thing we learned through hard experience is that applications always change; there’s always new features, new demands. And after a couple of years trying to do this on a SQL database, it can start to look a bit… weird!
“You can fix that, but then you need to re-plan your structure, re-plan your work. We want to be really quick to make changes and that’s harder when we have SQL.”
Shopping for a new database, the Toyota Materials Handling team went to vendors with an eight-point evaluation criteria that would determine what they chose to use; closely assessing Apache Cassandra, Couchbase, and MongoDB, among others, before settling for the latter.
Sahir Azam, Chief Product Officer, MongoDB, is proud of the win and attributes it to three key fundamentals that help businesses capture value from the Internet of Things.
He notes: “These are a document data model that lets customers manage and incorporate data in any structure. This allows them to launch and iterate applications quickly without the burden of disruptive schema changes. Secondly, scale: IoT applications process great volumes of data through sensors so systems will need to scale quickly and affordably. Atlas has the ability to do that across all major cloud providers across 70+ regions globally. Thirdly, real-time analysis. Apps handling fast-moving IoT data can’t wait on processes to replicate data to a data warehouse. They need to react and respond in real-time. MongoDB’s rich indexing and querying capabilities, including aggregations, geospatial and text search allow users to ask complex questions of the data in real-time.”
Back in the world’s warehouses, meanwhile, the applications the team can now offer across an increasingly semi-automated materials handling industry vary widely: “Customers want to be able to remotely stop a forklift from entering a certain area, for safety reasons.
“They might want KPIs on utilisation, collisions, driver performance… Forklifts cost a lot of money: so does insurance. Our applications can help reduce costs significantly for our customers.”
Improving driver performance is also a focus. As Toyota’s Spong puts it: “Forklift drivers typically stay in their jobs for a maximum of two weeks before wanting to go and do something else. By the end of their time in the job, they get reckless. We’ve built a gamification model that ranks driver performance that has proved really popular with drivers, while managers can track and reward good performance.”
Ultimately though, those levels of churn are unsustainable. The developers don’t want to talk too much about it (“that’s another department” they say, with the faintest sneer) but Toyota is now providing over 4,000 fully automated forklifts to customers around the world.
With them are coming fundamentally different shaped warehouses, with old conveyor systems in some being replaced with automated forklifts, for example to free up storage space. Software may be eating the world, but it’s not eating up space: here, a developer-led idea that was ahead of its time is transforming the future of materials handling and significantly greater efficiency and safety are just on the horizon, whether the product is beds or boursin.
