Predictive Maintenance and Vehicle Telemetry

Gains:

• Ability to explain the nature of CAN bus, telematics and sensor telemetry and the value of predictive maintenance throughout the fleet/vehicle lifecycle.
• Ability to establish an artificial intelligence workflow in anomaly detection, remaining useful life (RUL) estimation and fault code interpretation
• Ability to verify predictive maintenance output by balancing false alarm cost, maintenance window and safety margin

You can maintain a vehicle or a fleet (commercial vehicle, truck, bus, construction equipment group) in three ways. Corrective maintenance: fix it when it breaks (the most expensive because it brings sudden failure and shutdown). Preventive maintenance: replace every 15,000 km (safe but wasteful, because you also throw away the good part). Predictive maintenance: look at the data and predict "this part will fail after approximately 2,000 km" and intervene at the right time. Artificial intelligence is the technology that makes predictive maintenance possible. In this unit, we will see how vehicle data flows, how predictive maintenance models are established, and how to use these predictions safely.

Where does vehicle data come from? CAN, OBD and telematics

Tools constantly generate data:

• CAN bus (Controller Area Network): It is the internal network where the electronic control units (ECU) inside the vehicle talk to each other. Hundreds of signals such as engine speed, speed, temperature, gas position flow from here.
• OBD-II (On-Board Diagnostics): Standard diagnostic port; It allows you to read fault codes called DTCs (Diagnostic Trouble Code, e.g. P0301 = 1st cylinder ignition skip).
• Telematics / telemetry: The vehicle sends this data wirelessly (via a SIM card module) to the center. Position, driving behavior, engine status are monitored remotely.

This data is usually a time series: a series of values ​​measured at specified intervals (e.g., every second). This is the raw material of predictive maintenance.

Attention: Location, driving behavior and VIN (chassis number) are personal/sensitive data. Anonymization, data minimization and KVKK/GDPR compliance are essential when working with telemetry (details in unit 10). Do not send the raw VIN to a generic AI tool.

Three main tasks of predictive maintenance

1. Anomaly detection: Capturing deviation from normal behavior. For example, a turbo temperature is consistently 15°C higher than expected under similar conditions. The model learns the "normal", flags the deviation.
2. Remaining Useful Life (RUL) estimate: The estimated remaining operating time/distance of a component until failure. "This clutch reaches critical wear after approximately 3,500 km."
3. Fault classification / root cause: Predicting which type of fault has developed from sensor patterns and combining it with DTCs.

Step by step: a predictive maintenance workflow

1. Clarify the business question. What do we predict (which part, which malfunction)? How far in advance is early warning required?
2. Collect and align data. Timestamps of different sensors must be aligned, units must be consistent.
3. Tag/event description. Mark faults that have occurred in the past; the model learns from these. If there is no label, turn to anomaly detection.
4. Feature engineering. Extract meaningful features from the raw signal: moving average, vibration frequency components, temperature increase rate.
5. Model building and validation. Pay attention to the past/future distinction in the time series (danger of data leakage!).
6. Threshold and alarm logic. When will the "maintenance required" alarm appear?
7. Fielding and monitoring. Track the accuracy of alarms; reduce false alarm rate.

Tip: Do not use future training when evaluating the model in time series. An attribute such as "average of next 5 minutes" cannot be known at the time of prediction; this is a data leak and makes the model great in the lab but useless in the field.

Using RUL estimation correctly

Although RUL may seem like a single number, it is actually an estimate and carries uncertainty. Correct usage:

• Present with uncertainty range. "3,000-4,200 km (80% confidence)" instead of "3,500 km". The maintenance plan is made according to the worst case scenario.
• Add margin of safety. Intervene on the safety-critical part even before the lower limit of the estimate.
• Weigh the cost of a false alarm. Too early warning = unnecessary parts replacement and downtime; too late = failure. Balance is a business decision.

Approach

Advantage

Disadvantage

Corrector (when it breaks)

No planning required

Sudden stop, highest cost

Preventive (calendar/km)

Simple, safe

Waste of solid parts

Predictive (AI)

Just in time, less waste

Requires data, model, validation

Mini case studies

Case 1 - Anomaly in the fleet. The turbo pressure signal of 40 trucks in a cargo fleet is monitored. The model captures that in a vehicle, the pressure slowly decreases at the same load and speed; There is no DTC yet. When it was towed to service, it was seen that the turbo leak had started. Malfunctions and towing costs (approximately 900 EUR) on the road are prevented. Result: The anomaly gave an early warning before it turned into a fault code.

Case 2 - Data leak trap. A team establishes a brake pad wear model; Test accuracy is a staggering 99%. Upon examination, it turns out that the model uses a maintenance-record field (a column entered after a fault) that directly indicates wear as an attribute, that is, it sees the "answer". When this area is removed, the accuracy drops to 82%, but it is now realistic. Conclusion: A result that looks too good is a sign of data leakage.

Case 3 - False alarm balance. A battery health model produces 30 false alarms per week when the threshold is set too precisely; Technicians stop relying on alarms. By rearranging the threshold, uncertainty interval and two consecutive confirmation rules, false alarms are reduced to 4 per week and real failures are still caught. Bottom line: Alarm fatigue can render predictive maintenance dysfunctional; balance is essential.

prompt templates

Template 1 - Attribute suggestion (leakage controlled):

Role: You are a predictive maintenance data scientist. Task: Suggest candidate attributes for early turbo failure detection. Context: Signals: turbo pressure, exhaust temperature, engine speed, load; 1 sample per second; VIN has been anonymized. Constraint: Proposing attributes that cannot be known at the time of prediction (future/leak risk); flag leak risk for each attribute.Output: Attribute | justification | Leak risk (Y/N) table.

Template 2 - DTC interpretation:

Role: You are an automotive diagnostician. Task: Interpret the following DTC combination and list possible root causes. Context: P0300, P0171, slight idle vibration; last service 10,000 km ago. Restriction: Definitive diagnosis; cause in order of probability and give a verification measure for each.Output: Probable cause | verification | priority.

Template 3 - RUL interpretation:

Role: You are a reliability engineer. Task: Translate my RUL estimate into a maintenance plan. Context: Clutch RUL estimate 3,500 km, confidence interval 2,800-4,500 km; not safety-critical but stranded expensive.Constraint: Consider uncertainty and false alarm cost; don't trust odd numbers.Output: Recommended maintenance window + justification + remaining risk.

Template 4 - Alarm logic:

Role: You are a fleet tracking system designer.Task: Propose a draft alarm rule that reduces false alarm.Context: Model produces scores on the clock; technicians are experiencing alarm fatigue.Output: Rule (e.g. cascading confirmation, hysteresis) + expected impact.

Weak prompt / Strong prompt

Weak prompt:

Make a model that predicts engine failure.

It is not clear which fault, which signal, how far in advance, which verification.

Powerful prompt:

Role: You are a predictive maintenance engineer. Task: Design an approach to warn of turbo leakage at least 1,000 km in advance and write a verification plan. Context: Fleet of 40 vehicles, CAN signals, 12 previous fault records; VIN anonymous.Constraint: Prevent data leakage; RUL with uncertainty range; discuss false alarm cost; claim definitive diagnosis.Output: Step | method | risk of leakage | verification table.

Common mistakes

• Data leak. The attribute containing the future or answer produces pseudo-high accuracy.
• Thinking RUL is the only exact number. RUL without uncertainty range and margin of safety is misleading.
• Ignoring alarm fatigue. Too many false alarms will end the reliability of the system.
• Not protecting confidential data. VIN, location, driving behavior are sensitive; Anonymize.
• Timestamp/unit error. If the sensors are misaligned, the model learns a meaningless pattern.

In summary

• Predictive maintenance aims at “just-in-time” intervention through data-driven prediction; reduces waste compared to corrective and preventive maintenance.
• Data comes as time series from CAN, OBD and telematics; Anonymization and confidentiality are essential.
• Three main tasks: anomaly detection, RUL prediction, fault classification.
• Data leakage is the most dangerous trap; Maintain past/future distinction.
• RUL should be presented with uncertainty range, balanced by false alarm cost and safety margin.

Application task

Select a component (e.g. battery, brake pads, turbo). (1) List which signals reflect the health of this component. (2) Take attribute suggestions with template 1 and flag each one for risk of leakage. (3) Convert a RUL forecast into a maintenance window with uncertainty interval. (4) Define an alarm rule and write down your privacy measures to reduce false alarms.

checklist

• [ ] I clarified the fault to be predicted and the required early warning period.
• [ ] I checked the attributes for data leakage.
• [ ] I have presented RUL with uncertainty range and safety margin.
• [ ] I evaluated false alarm cost and alarm fatigue.
• [ ] I anonymized sensitive data such as VIN/location.
• [ ] I checked sensor alignment and unit consistency.