Product design, development, and reliability engineers need to verify that their product meets specifications, which include dimensional requirements, functional definitions, and life testing. How are the requirements validated?
Telematics data is collected to show how a vehicle has been operated. Fleets and retail data are stored on servers for engineering analysis. This data can be used to set new requirements or validate older requirements.
A common practice for a modified product is to repeat a prior specification with minor changes. However, the source and history of old product specifications may be undocumented, customer usage patterns change with time, and different markets have different requirements. Sometimes prior specifications have been compromised to meet cost and timing constraints.
Requirements have been based on customer surveys, “expert” opinion, or cost and timing compromises made during product development. However, surveys have flaws.
- Customer surveys show poor correlation to engineering data. Why? Survey questions are difficult to create and may be misinterpreted.
- Customers are not equipped with counters, measurement instruments, and data trackers.
- Surveys can’t include items that are invisible to the customer, but important to the component or system engineers.
With regard to experts, they have divergent opinions based on their professional experience. Finally, requirement compromises are inherently flawed. A telematics data driven approach avoids all of these issues.
Big Data is describes extremely large data sets. Big Data Analytics are the methods used to analyze these data sets. The goal is to uncover hidden patterns, unknown correlations, market trends, customer preferences and other useful information contained in the data. These terms are applied to the massive data sources used by different industries and to future data sources like the Internet of Things (IOT).
For example, marketers analyze customer demographics and purchase decisions to increase sales. Financial organizations infer critical investment news by analyzing the text contained in tweets. Recently, tweets have been analyzed to predict election results. An automobile company currently identifies early quality issues by analyzing the narratives included with warranty claims.
In the automobile industry, the CAN bus is a communication network that transfers information within the vehicle at a very high rate. The bus contains data on about 1000 CAN channels. The CAN channels are specified as part of the vehicle design and are the primary communication between electronic modules. The electronic modules continuously monitor the bus for the data required to perform their function and post data for other electronic modules to use.
During the product development process, automobile companies install special modules on development vehicles to collect and transmit data to a central facility for storage and analysis. This has been extended to include special vehicle fleets, some employee lease vehicles, and customers who agree to be monitored. The CAN data records are collected and time stamped.
The CAN data is collected at a high rate to support fault code diagnostics. When a fault is recorded, all CAN data for about 2 seconds around the event is retained and transmitted to engineers for analysis.
From the CAN data stream, 1-second data is recorded and saved for analysis. At regular time intervals, when module memory is low, or in response to various events, this data are communicated to a storage center. The process is captured with the following graphic.
The analysis of the 1-second data has been weak because of the massive amount of data from individual vehicles and fleets of vehicles. For example, in a year, a typical vehicle will generate 2.6 million time stamped records containing about 1000 readings, in a 2.6 Gigabyte file. For one company, about 10,000 vehicles have been monitored during the last 5 years.
To support analytics, Matlab software and graphics were developed on a laptop computer, to characterize fleets of about 100 vehicles. This was a proof of concept for software and methods that are extensible to the analysis of the large fleet data using distributed processing and large servers.
Upon reviewing the raw data, it was noted that some channels became intermittent or contained unrealistic data. Bad sensors, electrical connections, and module monitoring issues caused these problems. This suggested the application of statistical methods to characterize customer usage.
The vehicle CAN bus messages names were defined by independent design groups. The result was the CAN data channel names for the same variable are inconsistent across vehicle platforms. Data name translations are therefore needed when compare vehicle parameters across different vehicle types.
Measurement units presented a challenge. For example, vehicle acceleration was measured by accelerometers. While the data was recorded in metric units, some people reported the data as gravities of acceleration. The measurement units of the raw data are of fundamental importance for proper analysis.
A fundamental challenge is to analyze individual vehicles, each having different sale dates, operating times, and mileages. The solution was to standardized time and mileage metrics. For example, vehicle trips would be standardized to trips/day. Similarly, braking events would be standardized to events/mile.
Analysis of all of the available data was impractical on a laptop computer. The analysis focused on smaller vehicle subgroups that were extracted and analyzed. One approach was to subgroup the data by fleet, year, model, engine and/or transmission. Another analysis partitioned the data into passenger cars, trucks, or SUVs. Another compared retail vehicle usage to police fleet usage.
Passenger car design targets vary from company to company, but typically are 10 years or 150,000 miles. For critical components, safety systems, and emission systems the targets may be higher. For example, emission systems, like Diesel engines or engine stop-start system, have a 15 year and 225,000 miles target, set by regulatory requirements.
With the corporate design targets established, the standardized metric for each vehicle is projected to the corporate target. For example, trips/day could be projected to 10 years of operation.
Automotive companies set aggressive design verification targets. Frequently, the 5thor 95thusage percentiles are specified, depending on the system or component potential failure mode. The 95thpercentile usage may be selected when high usage drives wear-out. An example would be switch mechanical wear-out. Alternatively, when failures occur with low usage rates, the 5thpercentile target is used. For example, a battery may become discharged during many short trips; therefore the 5thpercentile of trip duration may be used to set a design target.
Telematics supports the creation of data driven requirements. The methods have not been defined but will be covered in future articles.
This is the first of a series of articles on the analysis of vehicle usage data and will use automotive examples. The company, vehicle models, and customer information were removed for privacy concerns. Instead, the general analytic methods and examples, applicable to many products in different industries, will be presented. My goal is to show how telematics data may be analyzed to validate and improve product requirements through improved knowledge of usage.
If you want to engage me on this or other topics, please contact me. I offer a free hour for the first contact to discuss your problem/concerns and to determine how I can help you.
I have worked in Quality, Reliability, Applied Statistics, and Data Analytics over 30 years in design engineering and manufacturing. At Wayne State University, I taught at the graduate level. I have provided Minitab seminars to corporate clients. I write articles and present and at SAE, ISSAT, and ASQ. I want to assist you.
Dennis Craggs, Consultant