Internet of Things primarily makes granular information more accessible in real time. However for ioT to take off, we need to show case the technology within a business scenario that can generate a multi-fold return on investment, so that the technology adoption can take off.
Information availability in real time alone doesn't add value, or may not add sufficient value to justify the costs and risks associated with an ioT project. To get around this we researched industries and where a combination of an innovative business model that could be executed only through the availability of real time granular data.
We looked around for business situations where the availability of granular information can add substantial value. We found that in the after-market automotive care. We further narrowed down the industry to only large trucks and only one part of the truck which is the tire. Tire manufacturers carry very high levels of tire inventory and so does the channel. We analyzed a few companies and found that the inventory holding was in billions. A good example was Good year Tires which had 10.5 Billion sales with over 2.6 Billion in finished goods inventory. The past three years were in the 2.4 to 2.6 billion range as well. The cost of holding inventory in this industry seemed to be between 40% - 55% according to our analysis. This meant that the carrying cost was over a billion dollars and cutting even a small percentage of the inventory will translate into a multi-million dollar cost savings.
We created a business model that is based on usage inspired by Amazon Web services. AWS has allowed businesses to pay for IT infrastructure based on their usage. We realized that we could replicate this for a completely different industry. When customers pay based on usage, their incentives are usually aligned with that of the Managed Service Provider. To align the incentives of the Fleet managers with the managed service provider, we created a usage based billing model for Fleet management. While initially the model will be a simple cents per mile model, more complex measures could be derived that would provide an incentive to the managed services provider to continue lowering the running cost per mile of a truck as long as they get a share of the cost reduction.
The AWS solution architecture is shown below
The Fleet Owner or customer wants to maximize the miles and uptime on his trucks as they are a proxy for his revenue. The managed services provider also has the same metric thus aligning the incentives of the supplier and customer.
What it takes to Manage a fleet
Managing a fleet of trucks means minimizing the downtime, optimizing the fuel efficiency both of which depend a lot on tires. The business model we are proposing is inspired by the Amazon Web Services but to revolutionize the fleet management and make it a mileage based pricing instead of pricing it based on tires or specific parts. A fleet management operation wouldn't worry about what the condition of tires are and will pay the managed services company on miles traveled.
What it does
A managed service business of this kind would need to maximize the tire usage without affecting the truck downtime. To do this we will use AI based predictive and forecasting Models that predicts when the tire wear is likely to happen and then create a preventive maintenance schedule. The tire wear prediction engine going into the future is built on top of an IOT sensor base which collects data from each truck every second or minute through out the day including mileage, Truck load, Temperature, picture of the road, Tread depth, Tire pressure. Using this granular data, windowed aggregates are computed that include velocity of the truck, acceleration events by level, braking events by level, tread wear per load miles, road condition category from the picture and then computes the expected wear of the tire for the next week and if any of the tires need replacement. This data is then aggregated at the fleet level to calculate the number of tires that require replacement in the coming week, create a maintenance schedule for these trucks and then send the maintenance schedule to the fleet management company.
How we built it
We designed it in such a way that all of it could be run on AWS with a complete serverless architecture. Since real time data from the trucks was essential for the demo, we built a data generator that simulated a fleet of trucks each with a serial number and initialized them with mileage. To reduce costs of course we only put one truck per customer and had two customers/fleets and initialized the customer data.
We simulated a set of sensors providing the tread depth at sub-millimeter resolution that is inbuilt into every tire. Each tire on the truck has a unique identifier that allowed us to track the mileage, tread wear at the tire level. The tires also had a position indicator to indicate where the tire is installed on the truck (steer wheels need to have more tread than the rear wheels). Accrued Mileage was collected from the truck every second. We used Kinesis Analytics to calculate various features such as average velocity, acceleration, deceleration, braking events, rate of tread wear using rolling and tumbling windows.
Challenges we ran into
Hierarchy of Things
Our use case demanded that each truck was a thing which had some sensors as well as there were some things that were connected to the thing in this case tires. Ideally we would have registered the things in a hierarchical fashion but there is no such capability in AWS IOT. To accomodate this challenge we introduced an edge device. We tested a raspberry pi connected to multiple sensors getting the data and persisting on the raspberry pi and then syncing the data. This introduction of edge device was also helpful in building a more tolerant logic that could live with network failures.
Issues with Kinesis SQL
It took us time to understand the syntax for Kinesis sql. The Kinesis SQL syntax was unlike general SQL and took a little bit of learning Curve as the Kinesis SQL was case sensitive.
Lack of Logging
Kinesis SQL application doesn’t provide any log in Cloud watch. This meant the only means for testing was through trail and error when the application didn't work as expected.
Debugging the Parsing Errors
Kinesis SQL parsing error messages were not very intuitive so we needed to perform some trial and error on sql queries before figuring it out.
API Throttling Errors
Within AWS we ran into issues when we tried to analyze images using Rekognition at a high throughput and encountered API throughput exceptions. We requested for throughput increase to ensure that the lambda pre-processor output was working.
Accomplishments that we're proud of
The architecture was completely serverless. We used ioT, Kinesis, Lambda and Rekognition extensively. An entire business model managing multiple fleets of trucks and charging for tires by the mile could be scaled up with very limited changes to the design. We did face some issues like API throttling, but we eventually overcame those.
What we learned
Learnt a lot about tire engineering, available sensors, tire life, factors involved in tire design, tire features for different types of trucks and their usage profile. Played with raspberry pi and tried to integrate data from multiple sensors. Finally for the demo we simply created a simple data generator that could create data coming from all of the tires and at the truck level in a single json which would have ideally come from an edge device residing on the truck.
What's next for Managed Tire Replacement Services - using ioT
- We ran the numbers and we believe that making the managed services business into an insurance which covers all types of truck maintenance with a truck uptime SLAs would become extremely viable. Once self-driving trucks start hitting the road the variable labor cost is eliminated making the transport miles per truck per day a priority. Currently limited insurance products are available for trucking companies and building these SLA guaranteed insurance products can be hugely profitable for both fleet management and insurance companies.
- Currently the Geo-location parameters are not being obtained, but having GPS feed would also give the location of the truck and can be used to integrate weather information. The sensor data in this project generated from the trucks, when combined with the GIS data and fuel consumption can be extremely valuable for tire manufacturers, especially their product engineering team. It will give them the ability to custom design tires for different geographies and load characteristics.
- Packaging the data and selling it to manufacturers can also be a valuable revenue source.
- Extend this information exchange all the way to the manufacturer so that they can manufacture in small batches only the required number of tires and build a connected supply chain. Tire manufacturers have high levels of inventory close to 3 months of inventory and any decrease in inventory can add to the bottom-line. We estimate that if Goodyear Tire was able to reduce their inventory by 10% they would be able to add an additional $105* million dollars to their bottom-line.
- We are reaching out tire companies, after market dealers and other industries where usage based billing would be of great value, giving companies the incentive to create products that can improve usage value of the product.
* Source: https://finance.yahoo.com/quote/GT/balance-sheet?p=GT assuming a carrying cost of 40%.