Fault detection and predictive maintenance are two important objectives of data science on automotive data. A car today has anywhere between 20 to 70 electronic control units (ECUs) which monitor and manage the dozens of complex subsystems such as engine, transmission, climate control, braking systems etc. In part 1 of this series on fault detection and predictive maintenance in automotive applications, we covered some of the background details behind this sort of data. We talked about several possible business applications or use cases. In this article we will discuss a high level “architecture” for this purpose.

Recap from Part 1

The overall business needs for deploying any analytics on such data could be

  • Statistical understanding of normal operating conditions for hundreds of different vehicle parameters
  • Detection/identification of root causes for fault codes and system failures
  • Shorten product development cycle by allowing faster iterations
  • Preventive maintenance at the consumer level

We also identified at least four different “layers” or levels of analysis with the ECU data:

Layer 1: Predict occurrence of fault or no-fault

Layer 2: Predict type of fault and identify factors influencing the occurrence

Layer 3: Correlate fault type and frequency to system-level failure logs (combining unstructured and structured data)

Layer 4: Use correlations extracted from 3 and time series analytics to predict real time or near real-time system-level occurrences.

Conceptual Data Analytics Platform for fault detection and predictive maintenance

No matter which layer make the most business sense, a “platform” needs to be established for capturing, storing, managing, transforming, analyzing and reporting using the data. Whether for off-site or onboard vehicle (OBV) analytics implementation, a data platform is required organize the collected measurements. The platform must be capable of:

  • Generating transformations on raw data 
    • To build data tables for descriptive statistics
    • To build training and validation data tables for predictive models
  • Allowing segmentation by module, date, event type for root cause analysis via data visualization
  • Identifying and ranking parameter influence on fault codes based on modeling
  • Providing predictive modeling functionality and a mechanism to deploy the predictive models

Any fault detection and predictive maintenance platform should thus allow the output of the telematics data to be consumed by engineers, technicians and potentially even the vehicle owners, as the capability matures beyond pre-production levels. Each of the modules is typically combination of several technologies that have to be properly integrated. For example, the data capture module requires combining GPS, wireless and database technologies. In this series, we are not concerned with all the different modules of such a platform. We focus primarily on the modeling portion over the next couple of articles because we are interested in comparing popular data science platforms such as R, Python, Spark, RapidMiner and H2O on their applicability or utility for classification problems of the type mentioned in Layer 1.

The next article in this series will get into the data collection and transformation with notes on key challenges associated with the analytics. Details about one of the main challenges – handling unbalanced data – was discussed here

Originally posted on Wed, Aug 19, 2015 @ 08:00 AM

Photo by Samuele Errico Piccarini on Unsplash

No responses yet

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

simafore.ai