Skip to Content
Main Content

How To Define Your IoT Solution - Segment 2: Applications for Mixed Assets & Fleets

While each of the Personas discussed in the first segment of this blog have very different purposes and needs, they all require data from a machine or asset, yet not all machines are able to communicate the same information to one back-office system.  And in most use cases the “fleet” is made up of different makes and models of machines causing even more challenges.  So how do you support a mixed asset or fleet environment to gain actionable intelligence?

A majority of solutions today that support this mixed asset (one make, many models) and/or fleet (many makes, many models) are derived from a vertical specific or niche need in the marketplace and require aftermarket hardware to be installed on the machine.  An example of this is CiDRA’s SMARThatch™ solution where they are providing preconfigured bolt on sensors and equipment to allow quality technicians the ability to remotely monitor the quality of concrete while it is in route to the construction site.  In this case they are selling the hardware, transport and back-office experience for use on a majority of cement truck makes and models.  This scenario highlights the challenge for OEMs who are building machinery and systems that are being leveraged across numerous vertical markets.

Let’s take a look at a couple of options being implemented to help OEMs solve this particular problem.


Once a device is programmed to communicate with a specific back-office, it’s no easy task to change that connection being that it could take months of code development and testing to properly transition.  With a majority of back-office environments, Application Programming Interfaces (APIs) are made available so that data sharing can occur between  different systems.  These APIs can be leveraged for Platform-to-Platform communications that will allow desperate Telematics systems the ability to share insightful data into multiple solutions that best fit the Personas being served.

Hardware Redirection

A second option utilized within Telematics is redirection of data from the hardware to a back-office environment of choice.  In theory this isn’t a challenging feat being that the various communications standards like MQTT, HTTP based APIs, and others are available. The basic connectivity schemas are there.  The challenge comes with coordinating the implementation, on-going support, and management of the entire solution.   An example of this is if a new feature is developed within the back-office, there is a very good chance that work  would be required at the module level  and would have to be performed by another organization or team.  In today’s fast pace development world, aligning the release of hardware and back office features to achieve alignment could be difficult.

Multiple Solutions

Yet another option, which is being used out of necessity rather than choice, is the use of multiple hardware/back-office solutions to get the value necessary for the end user.  For example, in one vehicle you could implement one module type and portal to deliver fuel usage information and then use a completely separate hardware/back-office solution to monitor maintenance.   While this method  can support  both value propositions, the cost and convenience of  multiple, separate solutions become a burden.  The cost to maintain multiple solutions includes support, data transport, module upgrades, etc. and will  grow over time.  In addition, usage of the solutions - would not be maximized being that an end-user would  need to flip between solutions.  This solution methodology is great for getting into market faster, but its longevity comes at a higher cost.

As with any product, clearly identifying and knowing your target customer is critical to the success of the product.  With Telematics, the opportunity for success is magnified considering the numerous personas that can gain value from the solution, the infinite layers of makes/models and the various organizations that can impact how a solution is developed and used.  Taking the time early on in your telematics solution design phases to define the scope, as well as using a steppingstone approach ie: target customer (a-b) , then add features to support customers (c-e) drives clarity around what value your solution is providing and will drastically increase your solutions success factor.




Related Blog Posts:

How to Define Your IoT Solution - Segment 1: Personas

Part 1: Telematics What is it and Why is it Important?

Part 2: Telematics and Data Collection

Part 3: Telematics and Data Transmission

Part 4: Telematics and Data Aggregation, Visualization and Storage

More on Telematics

Meet The Author

Chad Repp is the Business Development Manager of the CANect Telematics product family at HED where he works closely with internal and external customers to design, develop and implement best-in-class end-to-end Telematics solutions. Chad has over 20 years of asset mobility experience specifically in solution architecture and design. Prior to joining HED, Chad was the Manager of Business Development & Strategic Planning for Verizon Wireless supporting various end-to-end solutions focused on Telematics and IoT.

Please wait while we gather your results.

More Blogs

No documents were found matching your criteria