Building out for the Internet of Things (IoT): Use Case #2
By Tom Chalker, CTO and Howard Oliver, Founder and CCO, What If What Next
The Internet of Things promises ubiquity of services. Once physical devices are given an Internet identity then great things happen. People-friendly services can be attached to clumsy mechanical devices. Here’s another example of the transformative effect of IoT.
Taking the Pain Out of a Nuisance Task
Twice a year Canadian drivers face a minor hassle. It’s time to change the tires for winter or summer driving. Conceptually, it’s a simple task: Make an appointment, throw the other set of tires in the car and make arrangements for alternate transportation after dropping the car off at the service center. It’s annoying enough that the tires are heavy and they don’t all fit in the trunk, but scheduling is tricky because everybody else is trying to get this done in the same month interval.
Now let’s see how that can be simplified by IoT.
- Go to your service center once (during the off-season if you like) with your tires and ask for the Seasonal Tire Changing service. During a half-hour wait, the technician installs a match-book sized Raspberry PI (a small computer that has WiFi connectivity and costs less than $20) under the hood of your car and asks you to enter your home’s WiFi password on a secure terminal. That’s it. You’re done.
- Fall arrives. You get a email from the service explaining that they would like to change your tires for the winter season. They specify your address (your place of work) and ask if you would like them to proceed with the tire exchange at that address on the following day. You agree. By the end of the next day you are driving around on winter tires.
- Spring arrives. You get another email from the service offering to change your tires and asking if tomorrow would be appropriate. They specify your address. You agree. It happens the next day. Then you think: I’ve changed jobs and work at a different place. How did they know to come there instead? No matter. It’s not a problem. You are driving on your summer tires.
Now let’s look at the situation from the IoT point of view.
- Each day, on the hour, the software on the small device installed by the service uses its GPS hardware to record your position within its internal storage. Because it is asleep for the rest of the time, the device drains only a miniscule amount of energy from the car battery. Energy that is topped up by driving your car as infrequently as once every six months.
- Each day when you get home, just as the car is switched off, the device uses your WiFi to check in with the Seasonal Tire Changing service to see if a tire change is pending. Most days it is not so that is the end of the conversation.
- A few weeks before tire-changing season, each device that checks in is asked to consult its record of GPS positions and provide consistent two or more hour periods of time over that last month when the car has been stationary during the work day. Using the data from many devices on many cars, the Seasonal Tire Changing service calculates an optimal route for technicians to drive to all of the customers with their tires in the van and perform an on-site tire change and balancing. Confirmation emails are dispatched the day before.
- The next morning, based on the positive responses, an actual route is planned and the appropriate tires are fetched and service technicians are dispatched. At the end of the day, the changed tires go into storage for the next season.
The interesting point here is that two separate processes are being optimized here. You, as the customer, get your tires replaced on the day that is convenient for you merely by responding to an email. Simultaneously, the technician’s time is used extremely efficiently. They know which tires to fetch and have an optimal route to visit as many cars as possible. The worst case scenario is that delays or miscommunication with the customer result in a rescheduling of the tire replacement and loss of a couple of slots in the technician’s day.
This is what IoT brings to the table. Take a simple device (in this case a personal car) collect simple data (it’s GPS position) and integrate with a centralized or peer system. The result is intelligent emergent behavior. Its an analogue of what happens in nature: A bee works individually from a simple set of rules. Put a few thousand of them together and you get the emergent intelligence of a bee hive.
As an entrepreneur you might ask what has to be done to build such a system.
There are at least four steps involved:
- Electrical interfacing of the PI. Absolutely trivial. Connect the device to the hot (battery) side of the electrical system. Connect one sensor wire to the switched side.
- Software is written for PI. This is written by a software developer. It is a small set of Use Cases for dealing with sampling GPS data, contacting the service securely over WiFi when possible and responding, when asked, with coordinates of consistent GPS positions.
- Software is written for the Cloud. This is small; perhaps one man week of work. A service must respond on a specific URL when the service application calls. A Use Case allows the app to specify that is time to begin collection of customer tire change coordinates and, later, another Use Case defines how to report collected data. The service also requires a Use Case to allow a car device to respond on the same URL when it checks in. If coordinate collection is active, then a further Use Case defines how it must receive and store that data.
- Software is written for a PC or Tablet. This is the biggest piece. Expect to spend a few months here. This is software written by a team that looks at the Use Cases of the entire solution. It must be a centralized service that collects all of the data, performs route-planning, dispatches emails and creates a schedule for the technician. The same app would like also be used by the technicians directly to get their routes for the day.
Keep in mind this is a very specific example. By broadening the nature of the data collected in the car, a huge spectrum of other services can be offered. For example, what if the data from the vehicle’s diagnostic systems was relayed at the end of the day? What repercussions would that have for car servicing? The best strategy is to think broadly and work with raw data at the device level and apply data mining and algorithms in the Cloud. Who knows what applications the end user might suggest in the future that can be tapped from the data?