Going Beyond Just IoT GPS: A Cookbook for Mobile IoT Applications

Mobile IoT applications can be challenging to implement, when compared against their cousins in fixed locations. In other forms of IoT, it’s common for enterprises to acquire IoT as a packaged system that includes IoT devices, controllers, software, and even vertical-market-specific tools, instruments, and vehicles.  In mobile IoT, the applications are often assembled from discrete pieces, under direct supervision of (or even implemented directly by) users.  There’s power in doing that right, and major headaches if you get it wrong.

More Than Just an IoT GPS System

The goal in mobile IoT is to obtain real-world status information on assets that shift around a lot, so they can be brought into the control envelope of supervisors.

Many of the notions familiar to those who have deployed IoT in smart buildings or manufacturing aren’t practical in mobile IoT. Security can be even more challenging in environments with less static configurations, while the assets and elements themselves cannot be orchestrated from controlled facilities.  It may be difficult to achieve communication with mobile IoT elements under some conditions, and recommissioning elements that have failed is always more difficult and often impossible, at least in a prompt manner.  In short, mobile IoT will require the user frame the application in all respects.

The Ingredients

Mobile IoT users may be surprised to find that the most important ingredient in mobile IoT isn’t an IoT element at all, but a detailed analysis of the mobility characteristics and requirements.  All IoT offers a way of finding out about and interacting with the real world. But, with mobile IoT, the application must be aware of specific real-world and mobile elements, the contents of which must be both up-to-the-minute and comprehensive.

The second ingredient in mobile IoT is the sensor networking technology.  Some form of wireless connectivity is mandatory in mobile IoT applications.  Short-range local wireless protocols like Bluetooth or Z-Wave typically have limited support of mobile elements, and therefore cannot be considered. Practical options include both WiFi and cellular 4G/5G, and certain IoT-specific protocols (LPWAN, NB-IoT.)

The third ingredient is the sensors and controllers that support a suitable network technology and the information-gathering and control requirements identified in the first step.  As always, you want to select the simplest-to-operate devices capable of serving the mission.

The final ingredient is the software, which includes both application software and platform tools like public cloud “serverless” and event-handling software.  It’s best to pick software that’s as generalized as possible to avoid creating application silos if mobile IoT is used in multiple missions.

The Recipe

Start your mobile IoT recipe with a review of the scope of observation required.  Not all moving elements will need IoT tracking/control over the entire scope of their motion.  All warehousing, shipping, and receiving applications will track goods and vehicles, but in many cases, the tracking is required to be undertaken from within facilities, rather than on the road.

While WiFi can be deployed for in-facility tracking, a cellular or satellite connection would perhaps be best for true mobile IoT connections: on the road, sea or air.

In some cases, it may be difficult to ensure constant connectivity by any means.  You may need to be able to store results in a databank for delivery to be accessed when the connection returns.

Important!  Check to ensure that your selected wireless technology meets regulatory requirements for the type(s) of transportation you expect to use.

Step two is to decide what you need to know, and why.  For mobile IoT, it’s virtually a given that location will be required, but if your scope of observation shows that it’s enough to identify a facility where the mobile element is located, a network-provided location (facility ID) may be sufficient.  Meshing IoT and GPS for these purposes is well established.

On the other hand, shipping something perishable might require temperature control, but do you need to know the temperature, or whether a specific temperature has been exceeded?  Do the items themselves require monitoring, or can you monitor the vehicles in which they’re carried?  If you transship something, can you assume minimal time moving the goods from one transport vehicle to another?All of this will bear both on sensor technology and software architecture.

Important!  Many mobile IoT applications will involve damage liability risk or even risk of personal injuries.  Make sure you include information needed to support the regulatory and insurance requirements associated with your mission.

Step three is to select your mobile sensors/controllers.  Mobile IoT security and compliance risks are higher because the devices aren’t under direct control all the time, so consider the following points, beyond the normal requirements:

Step four is to select a data model to fit your needs as described in the earlier steps, particularly Step 2.  The model should always include the identifier of the IoT device, the time, the type of event, and any information that’s convened with the event.  Usually, this information will include the location of a mobile sensor.  This data model should include a link to appropriate records describing contents, handling requirements, insurance, regulatory, and other documents relating to the specific elements being tracked by mobile IoT.

Step five is to list the visualizations your application users will require.  Most mobile IoT applications will provide the ability to track movement, including mapping the track.  Other valuable visualizations include listing mobile elements by location, by time, or by contents, or the nature of the tracked elements.  These visualizations will be the output options, working from the data model, and you’ll want to select a reporting/analytics toolkit that creates them.

Step six is to select an event-handling strategy.  There are two broad options here; use public cloud “functional computing” or “lambda” serverless event processing, or process events in one or more of your own facilities, using servers and software.  The question of which is best is likely answered by the path an event will take from its mobile source.  Events that are connected via a call can be received centrally, but where events are generated as IP data messages, it may be best to use the public cloud to handle them whenever the range of mobile operations is large—a country versus a city.

The final step is to select software that supports your application, data model, and visualization needs and the event-handling strategy you selected in the last step.  Stay away from custom software development if possible.  It’s possible to build an entire mobile IoT application using tools from the major cloud providers, which often offer event-handling services based on their own custom tools.

For data center hosting of event-handling, look at open-source applications that are specialized to your own industry first, then at general event tools.  Be sure that your event-handling can feed your database and data model.

Finishing Touches

When you’ve completed all the steps, go back and review them in order and verify that you’ve done all the things suggested.  As you implement the system, take each step in the order described, taking care with each move to plan ahead and back-up to ensure that everything integrates smoothly.

When you’re done, it’s a high priority to run a pilot test and verify the correct configuration before a decision can be made on deployment at full scale.  Things will be difficult to fix once the IoT-enabled mobile units begin their journey.

In Conclusion

As with all IoT projects, mobile IoT applications ultimately must be designed to enhance worker productivity and improve overall efficiency.  Don’t forget these goals as you follow the recipe, and try to avoid getting bogged down in buzzwords and concepts.  Remember traditional IT application practices – IoT may be novel and exciting, but it relies on many of the same principles after all.