New Approaches to Vehicle Health Management via a Digital Twin

Abstract

The connection of a vehicle to the cloud in combination with machine learning algorithms offers new approaches to vehicle health management. New insights are gained not only by monitoring an individual vehicle but also by comparing the meta-data of an individual vehicle with those of the entire fleet. A benefit of these insights is better prediction of the remaining useful life of a chassis component, which enables preventative maintenance and in turn increases the vehicle owner’s perception of enhanced vehicle dependability. This is particularly important in the context of automated vehicle fleets, which are expected to have a much higher usage rate than privately owned cars. Further benefits include reduction of warranty and cloud-based root-cause analysis.

The paper covers the underlying concepts of vehicle health management, including the “digital twin,” and describes a steering use-case, as well as Integrated Vehicle Health Management standardization frameworks.

1 Introduction: Value Drivers for Vehicle Health Management

1.1 Value Drivers

Integrated Vehicle Health Management (IVHM) is a system that uses data produced by the vehicle to assess the vehicle’s health, predict time to failure and isolate problems to their root cause [1]. It comprises a set of tools, technologies, and techniques for automated detection, diagnosis, and prognosis of faults to support vehicle platforms more efficiently [2]. An IVHM system identifies degradations that will lead to a failure that is unsafe, expensive, or creates major inconvenience to the customer [3]. Such systems are already established in the aerospace and defense industries.

As these systems are finding their way into the automotive industry, they are generating value for all stakeholders: Vehicle and Component Manufacturers, Auto Dealerships, and vehicle owners. Figure 1 provides an overview of the value drivers for each stakeholder. These can be categorized as Cost Avoidance, Cost Reduction, and additional opportunities for Revenue Increase.

Fig. 1.

Value Drivers for Vehicle Health Management

In summary, with IVHM vehicle manufacturers achieve a more capable and efficient process that enables them to create a higher-level product while consumers enjoy a more reliable product that is less costly to maintain.

1.2 Warranty

A good example of a value driver for a vehicle manufacturer is cost avoidance via warranty mitigation. In particular, issues that are labelled No Trouble Found (NTF) are minimized. Figure 2 summarizes worldwide auto manufacturers’ warranty claims per year [4]. For a typical manufacturer, the burden can amount to $115/vehicle/year. This warranty cost includes the replacement of components or sub-components that are not defect.

Fig. 2.

Worldwide Auto Manufacturers’ Warranty Claims per Year

Figure 3 depicts an example pareto chart that summarizes the warranty claims of an Electric Power Steering (EPS) system over 1 year. As shown, 30% to 45% of parts get labelled as NTF – no trouble found. This defect code is used to categorize field returned parts that appear to operate as specified after root-cause analysis.

Fig. 3.

Example Distribution of EPS Warranty Claims: NTF, no trouble found.

The potential reasons for not finding the root cause of an issue include differences between test and operating environment, weaknesses in testing machine design, defect of another component or replacement of a part out of convenience as part of a larger problem. Either way, NTF is causing inefficiencies and cost.

1.3 New Vehicle Technologies

Driven by new functions and features, vehicle designs are becoming increasingly complex. An example in the context of automated driving is Steer-by-Wire (Fig. 4). Redundant communication and processing paths ensure fail-operational safety. However, layers of redundancy impact component cost and system reliability.

On the other hand, prognostics and diagnostics reduce the probability of failures during operations in the field. At the same time, technicians who need to maintain innovative components that they may not have been trained for receive the guidance they need.

Fig. 4.

Steer-by-Wire

2 IVHM Framework

2.1 SAE JA6268 Capability Model

The SAE Surface Vehicle and Aerospace Recommended Practice JA6268 [5] provides best practices and a methodology to implement IVHM functionality. It also includes a capability model with maturity levels 0 to 5 (Fig. 5).

Fig. 5.

SAE JA6268 IVHM Capability Model

In this Model, a significant transition occurs between level 2 and 3. At this point, manual diagnostics and repair is augmented by prognostics and predictive analytics, which significantly enhances the capabilities of the IVHM system. Proactive alerts become possible before a component actually fails. Remaining Useful Life (RUL) is an important indicator generated in level 3.

Cloud computing and telematics are underlying technologies that enable remote health monitoring and are introduced in level 2. Data can be collected in real-time, analyzed for trends and compared with those of the entire vehicle fleet.

In level 4, the capability is expanded from individual components to the entire vehicle. And finally, in level 5, the health management capability is integrated into the vehicle controls and becomes self-adaptive. At this stage, the system optimizes itself in the presence of a component degradation.

In the auto industry today, most manufacturers have a capability level of 1 or 2. In the aerospace and defense industries, the capability level extends to levels 4 and 5.

2.2 IVHM Architecture in the Automotive Context

In an automotive context, an IVHM system comprises the vehicle, backend entities of vehicle manufacturer and service providers, the service organization of the dealerships, and the component engineering of the component manufacturers. Figure 6 gives an overview of the data exchanges between these entities.

Fig. 6.

Runtime Data Exchange framework

The software of a vehicle component such as Electric Power Steering comprises a component model. Sensor data are input into this model, which then provides the Vehicle Health Manager with a range of indicators, such as Defect Trouble Codes (DTC), Condition Indicators (CI), and Usage Indicators (UI).

The Vehicle Health Manager compiles and buffers the component indicators and sends them to the Vehicle Health Management system off-vehicle in the backend. To improve diagnostic quality and automate root-cause analysis of an anomaly, indicators can be provided to a diagnostic/prognostic reasoner. The benefits of performing the necessary computations in the cloud include the availability of big data analytics, automated machine learning, and indicator comparisons with vehicles from the entire vehicle fleet at a lower cost.

Two major outputs are sent back to the Vehicle Health Management system:

• 1. Diagnostic and Prognostic Health Reports with root-cause analysis and RUL indicators.

• 2. Updated component model parameters for downloading into the component software in the vehicle.

A system analysis and integration strategy with regards to the so-called IVHM functional block (Fig. 7) can be performed via the layered ISO 13374 reference model [6, 7].

Fig. 7.

IVHM reference model in ISO 13374 model

In this model, the lowest layer is Data Acquisition of raw data from chassis sensors, e.g., the torque sensor in an EPS. Data Manipulation – the next layer up – is responsible for tasks such as normalization, regime recognition, and triggering of signals, as well as synthesizing of virtual sensors that feed into the State Detection layer.

Feature extraction and the aggregation of CI occur in the State Detection layer. Statistical properties and time-frequency analysis, such as Short-Time Fourier Transform (STFT), are typical examples of feature extraction techniques. CIs give initial physics-inspired insights into the system.

The goal of the Health Assessment layer is to detect anomalies and isolate faults, i.e., to determine the root cause of abnormal behavior. Operating conditions and modes influence the behavior of the system. Hence, performance of the system needs to be modelled to take operating mode and environment into account. This can happen via a physics-based model; a data-driven model, i.e., via machine-learning; or a hybrid model between the two. Such a hybrid model is applied in this paper and referred to as a digital twin.

In the Prognostics Assessment layer, the system health is forecasted on the basis of the current state and projected usage. For this purpose, degradation and damage propagation models are included in this layer. The RUL is extrapolated within confidence bounds. And finally, the Advisory Generation layer provides actionable information to manufacturers and maintenance personnel at the dealerships.

The lower layers of this model are implemented in the vehicle in real-time, and the upper layers are located off-board in the cloud. Depending on computational requirements, the Health Assessment layer can be found either on- or off-board.

3 Digital Twin

3.1 Digital Twin Over Product Lifecycle

A generally accepted definition of a digital twin is “a virtual representation that serves as the real-time digital counterpart of a physical object or process” [8]. However, depending on the specific application, different interpretations of what a digital twin constitutes are possible. The focus can be on infrastructure, data models, or different components of the value chain [9].

In the context of this paper, a digital twin is understood as a combination of models that are refined and updated throughout the product lifecycle and help generate diagnostic and prognostic insights for the service operations in the field (Fig. 8) as part of cloud-based run-time prognostic and diagnostic services.

Fig. 8.

Digital Twin over Product Lifecycle

The model parameters applied in the digital twin can be updated and refined over the product life and thus increase the diagnosis and prediction ability of failure modes. However, to generate labelled training data it is important to ensure an acceptable degree of initial prediction accuracy of the classifier with a minimum of computational cost and a minimum of failure injection tests. This objective can be achieved with hybrid physics and machine learning-based data models [10]. Knowledge from the design of the physical system and observed data during operation are combined.

To enable the traceability of design-time and run-time data over the entire lifecycle of a component, the digital twin is complemented by a Digital Thread [11], which includes all component data, such as requirements, product records, and performance data, and supports the identification of the root cause of an issue.

Fig. 9.

Digital Twin Architecture

Both models (Fig. 9) operate simultaneously, whereas the physics-based model feeds into the machine-learned data model. The combination of both models may enable a reduction of the order of the physics-based model while improving the prediction accuracy of the data model.

The digital twin is fed with Condition and Usage Indicators and with diagnostic data, i.e., Defect Codes. The classification output serves two purposes, i.e., it provides:

• 1. A discreet green/yellow/red Health Indicator (HI) to alert the customer and maintenance personnel, and

• 2. Input into the Advisory Generation, which specifies corrective actions, test procedures, and alert codes.

3.2 Comparable Vehicle Class Evaluation

Operating prognostic services in the cloud is a cost-efficient way to perform computationally expensive operations that are needed only on an infrequent basis. Monthly prognostic RUL calculations or an automatic root-cause analysis once in the life of a vehicle are examples of potentially complex computations.

In addition, the location in the cloud offers the opportunity to compare indicators over the entire comparable vehicle class, rather than just analyzing indicators for a specific vehicle. This benefit results in additional diagnostic and prognostic insights (Fig. 10).

Fig. 10.

Comparable Vehicle Class Evaluation

4 Results from Electric Power Steering

4.1 Failure Injection Setup

The following section covers a practical example from EPS. The setup includes a pinion-to-rack interface that transmits torque, a connection to the tie rod that is secured and adjusted by a tie rod joint, and a jam nut. The EPS is mounted to the chassis via fasteners. Any mis-adjustment or loosening of any of the nuts, fasteners, or joints has a negative impact on steering noise, comfort, and eventually safety (Fig. 11).

Fig. 11.

Failure Injection setup

In the study, a total of 13 failure configurations were created at these interface elements. A standard frequency sweep of the steering system was performed, and the resulting root mean square (RMS) value at the steering wheel was recorded (Fig. 12). The magnitude of the failure conditions was chosen such that they were out of specification but may not have been quite noticeable for an average driver; furthermore, they were not at a safety-critical level.

Fig. 12.

Confusion Matrix and Frequency Sweep

4.2 Results

The baseline which the detection algorithms were compared was created via a classical “window model.” That means that for each configuration, three ranges of rms values were defined: a “good” range, which covered acceptable rms values; and two upper and lower “bad” ranges, which covered inacceptable rms values (Fig. 13). Bad ranges result in a Health Indicator alert.

Fig. 13.

Baseline from Window Model

The limitations of this approach can be seen in a Receiver Operating Characteristic (ROC) curve that plots the true positive detections over the false positive detections. The wider the detection window, the higher is the probability that all failure configurations are captured, but, at the same time, the higher is the probability that “good” conditions are falsely identified as “bad.” On the other hand, a narrow window ensures that there are no false positives; however, not all faulty configurations can be identified (Fig. 14). Hence, a window model-based approach to failure detection is always dependent on making trade-offs.

Fig. 14.

Trade-Offs from Window Model

For processing in the digital twin, CI were generated from the amplitude and phase properties at pre-determined discreet frequencies (Fig. 15). They included, for example:

- Rack position/Motor torque

- Rack position/Motor position

-….

Fig. 15.

Generation of Condition Indicators

As shown in the ROC chart in Fig. 16, a substantial improvement in classification performance can be observed by moving away from a window-based to a CI-based approach.

Fig. 16.

Application of Digital Twin

In addition, the output of the digital twin provides the Advisory Model with a prediction of the root cause of the failure condition. Figure 17 shows an example of how the prediction confidence can be improved by applying a digital twin.

Fig. 17.

Classification input into Advisory Generation

It is difficult to generate sufficient training data for a machine-learning algorithm to ensure that it yields highly accurate predictions without risking over-fitting. To do so requires a large sample size of components that are subjected to a sufficiently large number of failure-injection tests. A priori knowledge of system design and behavior that is captured in a physics-based model can close the gap. An overview of different options to combine data- and physics-based models can be found in [10].

4.3 Mapping into the JA6268 Process Model

The SAE JA6268 describes an Integrated Reference Model that consists of a Fault Model, a Processing Model, and an Advisory Model. The Processing Model specifies signals, data recording files, algorithms, Indicators (DTC, CI, UI), and calibration values. The Fault Model covers Failure Modes, Symptoms, Corrective Actions, Vehicle Functions, and Fault Consequences. And finally, the Advisory Model specifies corrective actions, test procedures, component identifiers, labor codes, alert codes, part codes, and effectivity tags.

Figure 18 summarizes how these models apply to the above discussed example and how they are mapped to the Health Management Stack.

Fig. 18.

Mapping to the JA6268 Health Management Stack

Elements of the processing model can be found on all layers of the stack, i.e., component, vehicle, vehicle manufacture backend, and component manufacture backend. Even though the Processing Model does not specifically call out Application Programming Interfaces (API) to help connect these layers, it helps to standardize them.

The Health Ready Components and Systems (HRCS) consortium [12] managed by SAE is helping to accelerate the adoption of SAE JA6268 with standardized model templates and nomenclature.

5 Summary

The connection to backend services enables the efficient application of digital twin models and the comparison of individual vehicle states to the entire vehicle class. Problems can be predicted and isolated and their root cause can be automatically identified. A hybrid approach to modelling (data- & physics-based) reduces the need for training data.

SAE JA6268 helps to standardize Design & Runtime Data Exchange of Integrated Vehicle Health Management. It provides a cooperative cross-industry approach that reduces costs for all stakeholders. The proposed approach generates additional value via Cost Avoidance, Cost Reduction, and additional Revenue Streams for all stakeholders.