Today’s vehicles are more sophisticated than ever, but increased complexity has brought with it more opportunities for systemic issues to creep in. Tried and true quality control processes such as FMEAs can help avoid established failure modes while pre-production testing can catch most early issues; still, some issues fall through the cracks. That’s why quality organizations employ teams of analysts, customer advocates, and field engineers to closely monitor and investigate complaints coming in from the field, so they can catch issues as early as possible and address them before they explode, requiring large scale corrective action.
But that job is becoming more challenging due to rapid changes in vehicle systems and the loss of tribal knowledge in quality teams as experienced analysts change roles or retire. It is taking teams longer to both identify and fix issues, which leads to higher warranty costs, lower customer satisfaction, and, ultimately, reputational damage. This struggle has been borne out in the data, asNHTSA records indicate a steady increase in recalls over the past decade (see Figure 1).
Big data – in the form of granularsensor data and diagnostic troublecodes – was supposed to"modernize" quality processes byproviding down-to-the-millisecondvisibility into the state of the vehicle,making detection andproblem-solving faster and easier.And after years of investment in datainfrastructure and visualization tools,that data should be more accessiblethan ever before. So why are qualityleaders still citing problem solving astheir number one pain point? 1
In this whitepaper we're going to explain the obstacles to utilizing connected vehicle data, outline the requirements for a solution, and show how Viaduct's TSI engine satisfies those requirements.
1 AIAG and Deloitte, Quality 2020
Problem-solving at OEM quality organizations is an inherently dynamic activity. (See inset “TheIterative Process in Quality Analytics” for a former Head of Quality’s account of a real-world example of the process.)
Every issue is unique – so users have to be able to move through their data in many directions. At various points,they may need to:
On top of all this, analytics are highly time-sensitive. Every day an issue remains open results in more defective vehicles finding their way onto lots and into the hands of customers.Given the exploratory, iterative nature of problem-solving in quality analytics,the challenge isn’t that there’s too little data; it’s that there’s too much.Thousands of sensors providing millions of data points at millisecond granularity can provide critical problem-solving insights – but only if you know where to look. For many quality teams, their automotive data lakes are like the internet before search: useful intheory, but cumbersome in practice.
We’ve broken down the problem into three distinct obstacles on the path to harnessing connected vehicle data for problem-solving in quality analytics: signal overload, lack of context,and lack of actionability.
“We were seeing a spike in repeat battery replacements, sowe decided to investigate. We first broke down replacements by manufacturing batchand software version to see if it coincided with any changes to the electrical system. Nothing popped out, so we decided to read closer into the claims.Generally most of them happened in cold weather,consistent with battery issues, and we couldn't find evidence of any special cause. It wasn't until we looked at the DTC that preceded these battery claims that we started to find a pattern. There was a lot of noise, and we went down a few rabbit holes chasing down DTCs that weren't significant, but eventually we saw that a quarter of them had relatively uncommon DTCs complaining about low coolant level.Looking at the individual notes for these claims, we saw that many of the technicians had checked the surge tank and saw that it was full. Assuming it was an electrical issue, theytested batteries and more often than not, due to cold weather, one or two would fail the test and be replaced.Often this would happen to clear the DTC. But in many of these cases the vehicles would come in a month later complaining about the low coolant DTC again, meaning thefix likely didn’t address the root cause.Next we looked for instances where that DTC had occurred but did not have repeat claims, and saw that the effective repairs had replaced the surge tank altogether. Looking at these, we found a single claim that complained that the coolant sensor had been stuck in the bottom of the surgetank.Finally we examined the incidence rate of co-occurrence of the low coolant DTC and surge tank or battery replacements across sensor suppliers, and saw a spike. We contacted the supplier and were able to fix the issue.”
Let’s say you’ve done the hard work of breaking down silos between data sources and making that data accessible to your quality team. For the individual quality analyst, there’s one more problem: knowing where to start. Faced with literally thousands of sensors and no way of 3 prioritizing them, most analysts are forced to ignore sensor data altogether. Instead, they are left with no choice but to comb through warranty claims, which, though valuable, rarely tell the whole story due to the fact that they are optimized for billing, not root cause analysis.
Let’s say you investigated an incident and found an associated signal that looks promising. Where do you go next? In order to make progress towards the root cause, you probably need to know what other vehicles this signal has occurred in, what signals are related, and what other issues vehicles experience downstream. Without better tools, each one requires you (or a dedicated data analyst) to write a new query with complex operations such as timing-based joins and filters that may not be familiar to a quality analyst.
In order to make a dent in quality costs, you need to take corrective action. But signals and failures are ultimately just symptoms; what you really need is to get closer to the cause, which typically lies somewhere in design and manufacturing. This requires relating your telematics data back to vehicle build and configuration data, such as part numbers, manufacturing batches, and vehicle trims, which you can only access by stitching together different data sources through a complex series of error-prone joins and filters. And all the while your colleagues in other departments are waiting on your reports so they can start triangulating the issue.
Solving these problems – signal overload, lack of context, and lack of actionability – requires three things.
