Three Keys to Making Telematics Work

Sept. 28, 2010


Mike Vorster
Mike Vorster
David H. Burrows Professor of Construction Engineering and Management at Virginia Tech. See ConstructionEquipment. com for full archives of “Equipment Executive.”
Standardization becomes an issue when it comes to disseminating and using the information. This is where a balance must be struck between knowing everything about one machine and knowing something about all machines.

Few meetings give the feeling of promise and excitement that I experienced at the recent Association of Equipment Management Professionals (AEMP) conference in Scottsdale, where I received an update on the collaborative effort underway to define key telematics data and make it available to end-users in a well-understood, standardized format. The work is essential for the future of our business. AEMP has taken the lead, and it is time for us to pull together and make sure that the initiative succeeds.

In March 1999, I wrote a letter to Mac Klingler, then manager of advanced research and development at John Deere. We were trying to wrap our minds around the huge potential offered by our emerging ability to instrument machines and wirelessly transmit the resulting data. We divided the system into four components with the following principal functions:

Collect and Buffer: to collect the outputs from the sensors, including the GPS antennae, store them, and prepare them for later transmission.

Transmit and Receive: to use the best available and most cost-effective technology to transmit the data to a central location either on demand or at preset intervals.

Process and Archive: to collect the received data, process them, produce the reports, and manage the vast flow of data.

Disseminate and Use: to disseminate the reports and graphs, and provide end-users with information tailored to their needs.

Much has changed in 10 years, and much has been achieved by manufacturers, software developers and suppliers. Most of the questions relating to the first three components have been solved. The question that remains, though, is can we disseminate all the information and build a business case based on improved day-to-day fleet management?

One of the folk with whom I have the privilege of working put it into context when he said, “The manufacturers and their engineers try to know everything about one machine. That would be nice, but I am a fleet manager with several hundred machines of different makes and models in my fleet. I need to know one or two things about every machine, not everything about one machine.” That is the challenge now being addressed by AEMP and the collaborative group it has assembled.

The diagram gives a good overview of the current state of play. Every company owns a mixed fleet and every machine can be fitted with telematics. Sensors can collect data and measure a wide variety of parameters. That part of the system is in place and working. Price points are coming down. Reliability is going up. In exchange for this, fleet managers must accept that every OEM and supplier will develop, implement and market their own technology. It is simply neither possible nor cost-effective to standardize the first two components of the system.

The same is true for the process-and-archive component. Every OEM and every third-party supplier will develop and market its own unique method, will use the data to improve its products, and will see its method as a brand-specific competitive advantage. The end-user benefits from the improvements, creativity and competition this generates and must again accept that standardization across a mixed fleet is neither possible nor, in most cases, desirable.

Standardization becomes a real issue when it comes to disseminating and using the information. This is where a balance must be struck between knowing everything about one machine and knowing something about all machines. Look at the three steps defined in the diagram for dissemination and use.

Step 1. These are the OEM and machine-specific machine health and performance reports now available from most systems. They tell you everything about one machine and make high-bandwidth use of all the archived data. They are valuable for specific forensic studies of machine health, performance, utilization and production, but they are a source of massive information overload when it comes to managing a large mixed fleet. The volume of information is overwhelming; the format is different for each hardware supplier; and accessing the information requires switching from website to website. Step 1information is for machine-health geeks. It will and should continue to be developed by OEMs and third-party suppliers as part of their competitive product development process. It will continue to be of value to fleet managers on an as-needed basis, but these reports and this part of the process will never find use on a day-to-day basis across the breadth of a large mixed fleet.

Step 2. These are the OEM- and machine-specific alerts currently in place. They are initiated at each supplier's site and follow the “red route” to individual managers' phone or e-mail systems. They provide minimum urgent information of value but have the potential to become overwhelming if not well managed. They are, in many instances, part of day-to-day fleet management, but no comprehensive telematics system can build a solid business case based on this as the only company-wide information produced.

Step 3. This is the step that the AEMP initiative seeks to achieve. It requires that protocols are developed whereby a limited number of standardized and well-defined data fields are exported on a regular basis along the “blue route” from the OEM-specific processing site to a company-wide telematics data manager that receives and integrates it into the enterprise-management systems. The challenge is not trivial, but it is doable. Three things must occur.

1) End-users must define the key telematics data they require to be available in a well-understood, standardized format. They must define the one or two things they need to know every day about every machine.

2) OEMs and third-party suppliers must develop the routines needed to push the data to each of their customers at agreed intervals. The technology is not new. It should be possible to “podcast” essential equipment-management data from OEM A to Company B every day.

3) Innovative and creative software developers need to develop telematics data managers that call for the defined, well-understood and standardized data available at each OEM specific processing site; combine it into a single company database; and provide it to the enterprise accounting, estimating costing and reporting systems.

Step 3 integrates telematics into the day-to-day corporate management system. Without it, the most promising fleet-management technology of recent years has no real business case and is destined to remain out in the cold. The AEMP initiative must succeed: There is too much at stake and there is too much money to be made.