DV Venture Insights: MachineMax: Building with IoT
MachineMax gives companies visibility of the activity of their machines, helping them run them more efficiently. CTO James Thimont gives us his insight into the venture’s deployment of IoT.
By James Thimont, CTO, MachineMax
In my time as CTO as MachineMax, a venture built by Shell and BCGDV, I’ve learned a lot about working with IoT. Although I had a comprehensive idea of what might be required and a good level of experience going in, I now have a far clearer perspective on the unexpected issues that can occur, and I’m also more aware of best practices that I wasn’t acquainted with before building the venture.
First off, let me frame the problem we were trying to address with MachineMax. The construction industry has a big problem with idling: When a machine’s engine is running but the machine is not active. Because companies have little visibility of their fleets’ activity, it is very hard to identify and eliminate periods of idling. We wanted to build a solution that would grant companies this visibility and thereby enable them to make cost and efficiency improvements, saving them time and money.
While a surface-level look might suggest this is a connectivity problem, it is in fact a data problem. A first instinct might be to connect as much hardware as possible and bring it onto an IoT grid, but taking a step back is advisable: Think about the data you need, and then work out how to connect it and when exactly you’ll need it; all the value generated by IoT comes from the data. To return to MachineMax, an approach focused on connectivity would have involved connecting the onboard systems of every machine. This would not have helped us, as we would only have captured engine running time, a metric which makes it difficult to accurately understand idling, the very thing we wanted to eliminate. We could measure engine revs, but this could easily be fooled by a machine operator tapping the pedals. Pursuing this approach would have led to a considerable amount of wasted time and expense without delivering value to our customers.
A renewed look at the problem, focusing on data, was more fruitful. Our engineers and data scientists looked for the data that would be an accurate proxy to understand a machine’s activity and identified that engine vibrations would give us what we needed.
From here, we needed to work out how to collect this data. This was another area in which having a great design team really helped: It’s easy to look at everything as a technical challenge, but combining engineering and design expertize allowed us to come to the right solution; many of the trade-offs you make building IoT products are between technical and operational complexity and this has a big impact on the user experience. For example, using an external power supply reduces the technical complexity, but the trade-off is poor user experience; in the case of off-highway machinery, connecting a power source is an invasive procedure that requires a technician and may invalidate a manufacturer’s warranty. We knew we needed a simple installation process, so our engineers got together to address the problem, eventually settling on an elegant solution: A ruggedized device with an accelerometer to sample the vibration that could be attached to the side of a machine with powerful magnets.
Another challenge was deciding when we need the data and deciding on the acceptable level of latency. It’s less obvious why this matters, but it has a big impact on the technical solution. The answer is derived from the customer use-case and what actions they’ll take. Our early customers all claimed to value real-time data, and providing this would certainly be a differentiator for MachineMax, setting it apart from the many telematics systems on the market which report once per day. However, to improve productivity and operating efficiency (safety is a different use-case), we analysed patterns and trends to give a more rounded view and comprehensive level of insight, feeding a previous day’s overview into a morning planning session, for example.
Crucially, we didn’t need real time data for this — delays of a few hours are acceptable. This made a big difference, as each data transmission uses a lot of power. Low-power networking technologies (such as LoRaWAN) give you real-time transmission capabilities but at a low bandwidth, limiting the amount of data you can send, and also require you to invest in networking infrastructure because there are very few public networks. But if you lift the real-time requirement, you can use technologies with existing public networks (such as 2G and 3G). This reduces the operational complexity and frees up bandwidth. Even though you transmit less frequently, the total amount of data is much higher and this can unlock different use-cases such as anomaly detection and predictive maintenance.
Once you have made all the technical decisions, it’s worth mapping them back to the real-world operating environment. Operating in the real-world brings challenges that you might not anticipate when testing in an office or a lab. The sensors may be in remote areas or challenging environmental conditions: MachineMax has global deployments from Northern Finland to India and the Middle East. There are multiple issues to be considered: Certain IoT technologies (e.g. LoRaWAN) require you to build a private network, which means installing gateways on site that need access to a reliable power supply and elevation; unless you’re operating in a perfectly flat environment, you won’t get close to the theoretical transmission range; different countries have different telecommunication regulations and operating frequencies; you may need to securely attach sensors so machines can’t be tampered with.
If you consider all these challenges from the beginning, you will have a much smoother and much more successful route to market. You also have to remember that the physical device is not the product, and it should not be designed in isolation from the rest of the system; you’re selling actionable insights and the user’s total experience (including operating and installing any equipment).
And as I have outlined, you’ll require a multi-disciplinary team: User-experience designers, engineers, and data scientists are all integral in building a solution that works from every angle. The best approach to building with IoT is to bring together multiple areas of expertise and people who have operational experience of the various IoT technologies.
For more on MachineMax, visit the website.
Want to find out more? Start the conversation with BCGDV.
