Beyond the Filler: On-Board Systems Evolve
The lineage of today’s driver and vehicle related on-board systems traces directly back to the cable-driven mechanical tach-o-graph, which was the on-board data collection device until well into the 1970s.
The lineage of today’s driver and vehicle related on-board systems traces directly back to the cable-driven mechanical tach-o-graph, which was the on-board data collection device until well into the 1970s. Tach-o-graph’s recorded (on a removable 24-hour or 7-day paper chart) engine rpm, speed, time-in-motion and time stopped. Manual chart analysis was then required to determine information such as driver hours worked and/or miles driven for payroll purposes. Similar manual analysis verified Driver’s Hours of Service Logs. An experienced analyst could also detect engine and transmission abuse by drivers, along with speeding and reckless driving patterns. The key word when discussing tach-o-graphs is “manual analysis.” A fleet of any size required full-time clerical specialists just to determine, in a timely manner, what “tachs” could tell them about vehicle operations and driver performance.
By the mid-1970s, the first generation of “on-board” computer systems, such as “Tripmaster” and “Cadec,” were a natural next-step evolution. These systems were capturing the same driver and vehicle data as the mechanical “tachs,” however the on-board computer could now be electronically downloaded (at end-of-route, end-of-day or end-of-multi-day trips) to a personal computer whose proprietary software would analyze the data and print reports in minutes for payroll, DOT compliance management, route analysis, etc.
From those first-generation on-board computers of 30 years ago, today’s wide array of on-board and in-cab systems applications can be broadly categorized as: 1) equipment- or vehicle-related-capturing and/or communicating equipment performance, maintenance scheduling, cargo temperature monitoring, real-time location, etc.; 2) driver activities-hours/miles driven, driving skills, speeds, off route deviations, stops and stop times, etc.; and 3) cargo information and sales data-customer stop and delivery volumes/time duration, customer inventory, on-board inventory, time and duration of door openings, delivery invoices, product returns, distance and drive time between stops.
In short, the combinations of on-board the vehicle and in-cab technology available today can tell users virtually anything about the vehicle and driver. It can be done on a real-time basis, if you are willing to pay for it. You can literally look over the driver’s shoulder and see how fast he is driving (and tell him to slow down) while he’s still speeding.
However, just as is the history with many other types of systems applications that began as “free-standing systems,” many of today’s on-board systems still have not been fully integrated into the overall business operating systems. Overlooked opportunities and underachievement are frequently seen. One common example is no data integration between the routing system and the on-board driver and vehicle “activities and events” recorders.
A delivery routing system (used in a dynamic mode or a static/fixed-route mode) must first build in basic routing assumptions about distance and time between delivery stops and stop times. Those stop time assumptions are then based on estimates of average time-per-case delivered. Over extended periods of time, these initial routing assumptions should be reviewed against actual performance and adjusted accordingly. However, the integration of daily actual performance from on-board miles, times, speeds and stop durations recorded can automate that process by feeding directly back into the separate routing and customer sales systems provides a continuous automatic source update of actual driving times and stop serving times vs. driving and stop assumptions built into the systems at origin. For example, a resulting new operating standard might be to automatically update the driving time assumption between route one’s stop A and B link (after every six repetitions of that particular link) as an actual average time and distance. The same can be done with individual customer stop times by automatic comparison of scheduled time-per-case delivered vs. actual times averaged over every six deliveries to that customer. Integration of scheduled vs. actual driving and delivery times are almost guaranteed to identify new opportunities for productivity, customer service and profit improvement.
The Dairy Distribution & Fleet Management Conference 2007 will be held March 28-31 at the Holiday Inn Select Airport in San Antonio, Texas. It will include a Vocational Tour of the H.E.B. Supermarkets’ state-of-the-art fleet maintenance facility. Visit www.dairydistributionconf.com for details.
The lineage of today’s driver and vehicle related on-board systems traces directly back to the cable-driven mechanical tach-o-graph, which was the on-board data collection device until well into the 1970s. Tach-o-graph’s recorded (on a removable 24-hour or 7-day paper chart) engine rpm, speed, time-in-motion and time stopped. Manual chart analysis was then required to determine information such as driver hours worked and/or miles driven for payroll purposes. Similar manual analysis verified Driver’s Hours of Service Logs. An experienced analyst could also detect engine and transmission abuse by drivers, along with speeding and reckless driving patterns. The key word when discussing tach-o-graphs is “manual analysis.” A fleet of any size required full-time clerical specialists just to determine, in a timely manner, what “tachs” could tell them about vehicle operations and driver performance.
By the mid-1970s, the first generation of “on-board” computer systems, such as “Tripmaster” and “Cadec,” were a natural next-step evolution. These systems were capturing the same driver and vehicle data as the mechanical “tachs,” however the on-board computer could now be electronically downloaded (at end-of-route, end-of-day or end-of-multi-day trips) to a personal computer whose proprietary software would analyze the data and print reports in minutes for payroll, DOT compliance management, route analysis, etc.
From those first-generation on-board computers of 30 years ago, today’s wide array of on-board and in-cab systems applications can be broadly categorized as: 1) equipment- or vehicle-related-capturing and/or communicating equipment performance, maintenance scheduling, cargo temperature monitoring, real-time location, etc.; 2) driver activities-hours/miles driven, driving skills, speeds, off route deviations, stops and stop times, etc.; and 3) cargo information and sales data-customer stop and delivery volumes/time duration, customer inventory, on-board inventory, time and duration of door openings, delivery invoices, product returns, distance and drive time between stops.
Today’s on board systems allow real-time monitoring of all truck and driver information.
However, just as is the history with many other types of systems applications that began as “free-standing systems,” many of today’s on-board systems still have not been fully integrated into the overall business operating systems. Overlooked opportunities and underachievement are frequently seen. One common example is no data integration between the routing system and the on-board driver and vehicle “activities and events” recorders.
A delivery routing system (used in a dynamic mode or a static/fixed-route mode) must first build in basic routing assumptions about distance and time between delivery stops and stop times. Those stop time assumptions are then based on estimates of average time-per-case delivered. Over extended periods of time, these initial routing assumptions should be reviewed against actual performance and adjusted accordingly. However, the integration of daily actual performance from on-board miles, times, speeds and stop durations recorded can automate that process by feeding directly back into the separate routing and customer sales systems provides a continuous automatic source update of actual driving times and stop serving times vs. driving and stop assumptions built into the systems at origin. For example, a resulting new operating standard might be to automatically update the driving time assumption between route one’s stop A and B link (after every six repetitions of that particular link) as an actual average time and distance. The same can be done with individual customer stop times by automatic comparison of scheduled time-per-case delivered vs. actual times averaged over every six deliveries to that customer. Integration of scheduled vs. actual driving and delivery times are almost guaranteed to identify new opportunities for productivity, customer service and profit improvement.
The Dairy Distribution & Fleet Management Conference 2007 will be held March 28-31 at the Holiday Inn Select Airport in San Antonio, Texas. It will include a Vocational Tour of the H.E.B. Supermarkets’ state-of-the-art fleet maintenance facility. Visit www.dairydistributionconf.com for details.
Looking for a reprint of this article?
From high-res PDFs to custom plaques, order your copy today!
