Predictive Maintenance vs Mileage- and Calendar-Based Maintenance

Decision-tree verdict

Buy predictive maintenance only after the baseline earns a fair comparison

The buyer's first branch is not algorithm versus spreadsheet. It is controlled maintenance versus uncontrolled maintenance. If preventive work is routinely late, defect reports are not reconciled, vehicle identifiers split across systems, and repair causes disappear into free text, predictive software will learn the administrative noise as readily as it learns mechanical degradation. Fixing those fundamentals can improve the operation while also creating the evidence needed to judge whether AI adds incremental value.

A defensible baseline combines the manufacturer's applicable service instructions with fleet-specific mileage, engine-hour, time, duty-cycle, inspection, and defect triggers. FMCSA's interpretation of systematic maintenance is deliberately not a universal interval table: it describes a regular or scheduled program and states that intervals are fleet-specific and sometimes vehicle-specific. That flexibility makes a disciplined baseline more important, not less. Buyers should document which tasks are controlled by regulation, OEM guidance, warranty, safety policy, observed wear, or operating experience before asking a model to move any date.

Predictive maintenance becomes attractive when a defined failure mode creates meaningful operational exposure, its deterioration appears in available data before functional failure, and the warning arrives early enough to secure a bay, technician, and part. It becomes weak when the label is simply 'vehicle visited shop,' the component can fail without a detectable precursor, or alerts arrive after dispatch can no longer be changed. The correct decision may differ by brake subsystem, tire, battery, aftertreatment system, cooling circuit, auxiliary unit, and trailer—even inside the same fleet.

That is why this guide recommends three outcomes rather than one winner: strengthen the interval program, add transparent condition monitoring, or run a bounded predictive pilot. A transportation and logistics software roadmap should preserve all three as compatible layers. The purchasing question is where each layer produces a safer, more actionable decision than the layer beneath it.

Evidence: fmcsa-systematic-guidance, bts-vius-summary, ecfr-39617

Three strategies, three clocks

Mileage, calendar, condition, and prediction answer different maintenance questions

Mileage-based maintenance schedules work from accumulated use. They are intuitive for components whose wear broadly increases with distance, and they fit odometer-centered planning, leases, and recurring preventive-maintenance packages. Engine hours may be a better usage clock for vocational trucks, power take-off work, extended idling, or auxiliary loads. A mileage threshold is not primitive merely because it is non-AI; it is transparent, inexpensive to audit, and often appropriate when failure risk rises predictably with exposure.

Calendar-based maintenance works from elapsed time. It remains necessary when materials age while parked, fluids absorb moisture, corrosion progresses, inspections must occur within a legal period, or a low-mileage asset still needs scheduled attention. Seasonal preparation, annual inspections, warranty requirements, and time-limited consumables often belong here. Combining time and mileage as 'whichever comes first' protects low- and high-utilization assets but can still over-maintain some vehicles and miss duty-cycle differences in others.

Condition-based maintenance reacts to observed state. A technician's inspection, oil analysis, tire pressure, voltage trend, temperature excursion, vibration pattern, fault code, or wear measurement may open work before the normal interval. The logic can be completely deterministic. Predictive maintenance goes further by estimating a future event or remaining useful condition from patterns across variables and time. The model may rank risk, estimate time-to-event, or detect behavior that differs from a vehicle's learned normal profile.

These are not mutually exclusive corporate philosophies. A reliability-centered program assigns the least complex strategy that controls each failure mode. Safety inspection can remain calendar-bound; oil service can use hours plus laboratory condition; a known fault code can trigger a rules-based diagnostic path; and one recurring component failure can receive a predictive risk score. The portfolio is the product. Treating every task as an AI candidate turns a targeted analytic capability into an expensive maintenance religion.

• Mileage or engine hours: best when exposure is observable and the service relationship is stable enough for a conservative interval.
• Calendar: best when age, environment, regulation, warranty, or inspection obligation advances even without vehicle movement.
• Condition rule: best when a measured state or diagnostic event has an understood response and does not require learned inference.
• Predictive model: best when multiple weak signals combine into useful advance notice and the fleet can validate performance on its own vehicles.
• Run to failure: acceptable only for non-safety-critical, low-consequence items when recovery and collateral effects are explicitly understood.

Evidence: doe-om-guide, fmcsa-systematic-guidance

Non-negotiable floor

AI can prioritize maintenance, but it cannot repeal inspection and safe-condition duties

For U.S. interstate commercial operations within scope, 49 CFR 396.3 requires motor carriers and intermodal equipment providers to systematically inspect, repair, and maintain controlled vehicles and equipment. Parts and accessories must remain in safe and proper operating condition. The rule also requires specified vehicle records, including a means to show the nature and due date of inspection and maintenance operations and records of their date and nature. A probability score is not a substitute for the underlying program or record.

Section 396.17 separately establishes periodic inspection requirements. Each vehicle in a combination is covered, and the relevant components must have passed an inspection in the preceding 12 months with documentation on the vehicle, subject to the regulation's detailed provisions and exceptions. Fleets operating elsewhere face different regimes, but the principle travels: predictive maintenance is an additional decision aid inside the applicable safety and inspection system, never a general exemption from it.

The compliance boundary matters during vendor demonstrations. A model may say a component has low near-term failure risk while an inspection reveals a defect that requires repair now. An optimization engine may recommend extending a task even though an OEM instruction, warranty condition, state inspection, lease covenant, or company safety rule fixes the limit. The workflow must identify hard constraints and prevent a model or dispatcher from postponing them. Every override should record authority, rationale, role, and time.

FMCSA's current Safety Measurement System methodology also treats Vehicle Maintenance as an operational safety category using applicable roadside-inspection violations. Its examples include inoperative brakes, lights and mechanical defects, load-securement problems, and failure to make required repairs. That measure is not a direct score for a predictive system, but it reminds buyers that the end state is roadworthy equipment, not a technically elegant forecast. Compliance, driver reports, preventive work, and roadside outcomes must remain visible beside model metrics.

Evidence: ecfr-3963, ecfr-39617, fmcsa-sms-methodology

Decision node 1

Start with a failure-mode register, not a platform feature list

A buyer should inventory failure modes before evaluating software. For each component or system, record how failure presents, whether it affects safe operation, whether it can damage adjacent equipment, how often it has occurred, how it is confirmed, what data precedes it, the repair action, part lead time, bay and skill requirements, and the cost of a false intervention. This turns a vague ambition to 'reduce breakdowns' into a portfolio of testable decisions.

The first branch asks whether the consequence requires a hard preventive control even when the model is quiet. Safety-critical and legally controlled work usually keeps inspections and conservative limits. Prediction may prioritize additional checks or flag abnormal deterioration, but silence should not waive the control without a separately validated engineering basis and appropriate authority. A buyer must also distinguish a service inconvenience from a roadside disablement, an out-of-service defect, a progressive fault, and a sudden random failure.

The second branch asks whether an actionable precursor exists. A precursor must be observable before failure and linked closely enough to the failure mode to support an intervention. A dashboard warning that arrives after derate begins may improve response coordination but is not necessarily prediction. Conversely, a gradual pressure, voltage, temperature, or duty-cycle signature may create useful lead time. Technical owners should state the mechanism before data scientists search thousands of correlations.

The third branch asks whether the fleet can do something different because of the warning. If the needed part takes four days to arrive and the model generally provides one day of notice, a true alert may still have little operational value. If the shop has no diagnostic slot, the alert becomes queue noise. Model selection should therefore follow the intervention design: the required horizon, tolerated false-alert load, inspection step, dispatch rule, parts policy, and person authorized to act.

1. Name the event

   Define the component, failure state, confirmation evidence, exclusions, and whether the outcome is a functional failure, safety defect, roadside event, derate, or planned replacement.

2. Map the mechanism

   Document expected precursors, sensor coverage, relevant duty-cycle and environmental factors, known confounders, and cases where failure can occur without warning.

3. Specify the action window

   Work backward from dispatch, diagnosis, part procurement, bay availability, and repair duration to define how much notice is useful and when an alert becomes too early or too late.

4. Keep the control boundary

   List regulatory, inspection, OEM, warranty, lease, and safety requirements that the prediction is not allowed to defer.

Evidence: nist-phm-roadmap, fmcsa-systematic-guidance, ecfr-3963

Decision node 2

Data readiness begins with one vehicle identity and one trustworthy maintenance timeline

Predictive maintenance needs more than a telematics feed. The analytical record must connect a stable vehicle and component identity to configuration, operating context, sensor observations, fault events, inspections, technician findings, parts, repair actions, and return-to-service status. If one VIN appears under multiple unit numbers, replacement components are not serialized, or a tractor's history is mixed with its trailer, the model may learn events that never belonged together. Identity resolution is therefore a safety and measurement control, not back-office tidying.

Time is the next control. Vehicle timestamps, gateway timestamps, vendor ingestion times, work-order open and close times, and invoice dates can describe different moments. Fleets need a normalized time zone, known clock behavior, and an event chronology. Otherwise, a repair can appear to precede the fault that caused it, information from after the outcome can leak into model training, and a backtest can credit an alert that operations could not actually have seen.

Sensor completeness and semantics also vary. Engine-connected devices may expose miles and engine hours, as FMCSA describes for compliant electronic logging devices, but an ELD is not automatically a full diagnostic or component-health platform. GSA's vehicle guide describes telematics installations capable of providing certain diagnostic trouble codes and engine-based alerts, which illustrates potential capability rather than a universal data contract. Buyers must inspect the exact parameter list, sampling and aggregation, firmware behavior, missingness, retention, and rights for each device and vehicle generation.

Finally, work orders need structured closure. 'Check engine' or 'repaired as needed' cannot reliably distinguish a confirmed component fault, preventive replacement, no-fault-found visit, duplicate complaint, campaign, accident repair, or unrelated service. Give technicians a small, usable cause-action-condition vocabulary with optional notes instead of turning every keystroke into a data-science demand. A data-management program should improve the technician's workflow and the asset record at the same time.

Evidence: fmcsa-eld-about, gsa-vehicle-guide, scania-component-x

Decision node 3

Rare failures, missing signals, and changing fleets make accuracy a dangerous headline

A predictive-maintenance dataset is usually imbalanced because a functioning fleet produces far more normal operating time than confirmed imminent failures. A model can appear highly accurate by predicting normal almost everywhere. Buyers should ask for the event prevalence, number of distinct vehicles and failures, label definition, observation window, warning horizon, and performance by asset cohort. Precision and recall must be tied to the decision, while the distribution of lead time shows whether correct alerts arrive when a shop can act.

The public Scania Component X dataset makes this challenge concrete without pretending to be a universal carrier benchmark. Its accompanying peer-reviewed data paper describes operational data, repair records, and specifications from more than 33,000 heavy trucks for one anonymized engine component. In the test labels, 4,903 of 5,045 vehicles are in the no-imminent-failure class, while the four failure-time classes contain 142 vehicles in total. A naive model can therefore look impressive on overall correctness while failing the very cases the fleet cares about.

The paper also documents practical collection limits: data can be unavailable when connections fail, service history is constrained to the manufacturer's network and official workshops, and rebuilt vehicles may no longer match the original specification. Publication anonymization protects confidential information but reduces direct interpretability for an outside operator. These are valuable warnings. A public benchmark can test engineering discipline; it cannot prove that a vendor will predict a different component on the buyer's mixed fleet.

Label quality requires adjudication. A part replacement does not prove the part was failing; it may reflect a preventive campaign, misdiagnosis, warranty policy, or opportunistic replacement. A roadside event does not prove the targeted component caused it. Build a review sample in which technicians, reliability engineers, and data owners inspect source evidence and resolve ambiguous events. Preserve the original label, adjudicated label, rationale, and confidence so the model team can distinguish mechanical uncertainty from clerical noise.

Evidence: scania-component-x, nist-phm-roadmap

Buyer comparison

Use this scorecard to choose interval control, condition rules, predictive AI, or a hybrid

The comparison below treats a well-run mileage and calendar program as the baseline, not as a straw man. It also separates deterministic condition monitoring from machine learning because many fleets can gain faster, more explainable control from rules before they have enough labeled events for AI. Score every candidate failure mode independently; a fleet-wide average can conceal a strong use case and several weak ones.

Weights should reflect consequence and operating model. A parcel fleet with dense service locations may value alert precision and rapid routing, while a long-haul carrier serving remote corridors may place more weight on warning horizon, coverage gaps, and repair-location planning. A vocational fleet may organize by engine hours and duty cycles rather than distance. The scorecard is a decision record, not a universal formula.

Evidence: doe-om-guide, nist-ai-rmf, nist-phm-roadmap

Make the incumbent visible

A strong interval baseline is a product with segmentation, exceptions, and evidence

Many AI business cases overstate value by comparing a new system with a nominal interval that the fleet does not actually execute. Establish the real baseline from dispatch and shop records: when each task became due, when the vehicle was available, when work began and ended, which tasks were completed, which were deferred, what defects were found, what parts were used, and whether the vehicle returned for the same concern. Separate policy failure from scheduling failure and maintenance-quality failure.

Segment interval performance by vehicle family, powertrain, component generation, age, duty cycle, geography, season, load profile, idling or engine-hour pattern, and maintenance location where sample size permits. If one subgroup experiences early wear, a revised deterministic interval or inspection may solve the problem faster than an AI platform. If wear varies continuously with several interacting conditions, prediction may deserve a pilot. Segmentation is not only modeling preparation; it is maintenance engineering.

Track due-date compliance without rewarding premature service. A shop that services everything early can show high compliance while wasting capacity and masking whether intervals are well chosen. Report service-age distribution around the due point, early and late reasons, unscheduled findings at planned visits, post-service repeat work, and availability. Pair maintenance cost with miles or service days only when denominators and accounting rules are consistent.

Preserve the baseline during the AI shadow period. The model should issue timestamped recommendations without changing work, while evaluators reconstruct what would have been known and what the existing process did. This creates a concurrent comparison against current season, fleet configuration, and shop constraints. Historical backtesting remains necessary, but a shadow run catches live integration gaps, missing data, alert delays, and operational ambiguity that a static notebook cannot reveal.

Evidence: fmcsa-systematic-guidance, ecfr-3963, bts-vius-summary

The transparent middle path

Condition rules often capture the first useful signal without an ML dependency

Before training a model, test whether the mechanic's decision can be expressed directly. A diagnostic trouble code combined with persistence, a sensor exceeding a verified threshold, a tire-pressure deviation, a voltage recovery pattern, a fluid-analysis limit, or a repeated driver defect may open an inspection. Rules can incorporate context such as ambient temperature, ignition state, vehicle model, or recent repair. Their logic, version, inputs, and outcome are easy to audit.

Rules are not automatically safe. A code may indicate a system symptom rather than the failed part; thresholds can be copied across incompatible sensors; intermittent connectivity can make persistence appear shorter; and firmware can change signal meaning. Every rule needs an owner, technical basis, applicable configuration, test cases, effective date, expected alert volume, and retirement process. Record the raw values and context that fired it so a technician can challenge the diagnosis.

The middle path is especially useful when failure labels are sparse but engineering knowledge is strong. It can improve structured evidence and technician feedback while the fleet collects outcome data. Those records may later support a model that combines several rules and continuous signals, but the model should demonstrate incremental benefit. If a learned score merely recreates a known fault-code threshold less transparently, it has not earned its complexity.

A condition-rule layer also provides resilience. During a model outage, suspended release, or data-drift investigation, critical deterministic alerts can continue. The schedule remains the ultimate fallback. Buyers should therefore ask whether a platform keeps rules, schedules, and learned models as separate versioned controls or hides them behind one undifferentiated health score. Separation makes testing, rollback, and accountability substantially clearer.

Evidence: gsa-vehicle-guide, nist-phm-roadmap, nist-ai-rmf

What the AI is actually doing

Classification, anomaly detection, survival, and remaining-life models are different products

A classifier estimates whether a defined event will occur inside a chosen horizon, such as an adjudicated component failure within the next service window. It can support a ranked inspection queue, but its result changes when the horizon or class definition changes. A twenty-four-hour classifier and a thirty-day classifier are not interchangeable. Calibration matters because a score used to rank assets may not represent a reliable event probability.

Anomaly detection learns or encodes normal behavior and flags departures. It can be useful when confirmed failures are scarce, but an anomaly is not a diagnosis. New routes, weather, loads, firmware, sensor replacements, or legitimate operating modes can look abnormal. The workflow must route anomalies for evidence gathering, not automatically order parts. Buyers should inspect the rate of alerts across normal seasonal and duty-cycle changes and the procedure for learning a new normal without erasing real deterioration.

Survival or time-to-event models estimate risk over time while accounting for assets that have not yet failed. Remaining-useful-life models attempt to forecast how much operation remains before a defined state. These outputs can align better with parts and shop planning than a binary alert, but they require careful censoring, event definitions, and uncertainty. A single countdown displayed without an interval or assumptions creates false precision. The Scania dataset's multiple time-to-event classes illustrate why timeliness can be built into evaluation rather than reduced to any alert before failure.

Ensembles may combine diagnostic rules, engineering features, temporal models, and fleet context. Complexity is justified only when it improves the business decision on unseen vehicles and periods. Demand a plain-language model card: target, horizon, population, excluded vehicles, input timing, label method, training period, missing-data policy, performance by cohort, calibration, limitations, human action, monitoring, and rollback. A serious AI development program makes those boundaries part of the product interface.

Evidence: scania-component-x, nist-ai-rmf, nist-ai-rmf-playbook

Decision node 4

Optimize for the cost of an alert decision, not the beauty of the model

False positives consume technician diagnosis, vehicle movement, bay time, and sometimes unnecessary parts. They can also teach the shop to ignore future alerts. False negatives can leave a qualifying failure unmanaged, but their consequence varies from a routine shop return to a roadside event or safety exposure. The threshold must reflect this asymmetry while respecting capacity. A vendor who reports one accuracy figure without the alert threshold and confusion matrix has not described the operating system.

Lead time has two failure edges. An alert can be too late to procure a part or reroute a load; it can also be so early that the condition is unconfirmable, creating repeated inspections and lost trust. Report the distribution of lead time for true alerts, not only the mean. Define a useful interval for each event, then score early, useful, late, and missed warnings separately. If the model repeatedly reissues the same warning, deduplicate it into an episode before counting performance.

Shop capacity turns statistical performance into economic performance. Estimate alert arrivals per week by location and season, diagnostic minutes per alert, bay and skill needs, part availability, and the percentage that can be bundled with planned service. Simulate a threshold against current queues before release. A model with higher recall can make fleet outcomes worse if it overwhelms diagnosis and delays certain preventive work. Capacity is a safety constraint, not a downstream implementation detail.

Use decision curves or cost tables with transparent local inputs rather than importing an industry ROI claim. Inputs may include towing, substitute equipment, service recovery, technician labor, part replacement, lost availability, cargo consequence, warranty coverage, and false intervention. Mark estimates separately from ledger facts and run ranges. The output is not proof of savings; it is a threshold hypothesis to validate in a controlled pilot.

• Precision: among alert episodes investigated, the share that meet the predeclared confirmation rule.
• Qualifying-event recall: among adjudicated target events, the share with at least one useful-horizon alert.
• Alert burden: unique alert episodes per 1,000 asset-days and diagnostic labor hours they create.
• Lead-time utility: share of true alerts arriving inside the action window, with early and late tails reported.
• Operational conversion: share of alerts reviewed, confirmed, scheduled, repaired, deferred, or closed as no fault found.

Evidence: scania-component-x, nist-phm-roadmap, nist-ai-rmf

Human authority

The technician closes the evidence loop; the model does not diagnose by fiat

An alert should arrive as a diagnostic work packet, not as a command to replace a component. Show the vehicle and configuration, target failure mode, warning horizon, triggering signals, relevant trend, data freshness, missing inputs, recent repairs, competing explanations, model version, and recommended inspection. Keep the interface short enough for a working shop while allowing deeper evidence when an engineer investigates.

Technicians need disposition choices that match reality: confirmed target condition, different condition found, no fault found, insufficient time or access, data incorrect, recent repair, duplicate, monitor, or escalated. Free text remains valuable for nuance, but a small structured vocabulary makes performance measurable. Never treat a lack of technician confirmation as a negative label when the vehicle was not inspected or the necessary test could not be performed.

Override is not model failure by definition. A technician may know about a noise, leak, route, load, repair, or configuration change absent from the data. Capture the reason and later adjudicate disagreement. Repeated overrides may reveal poor calibration, a missing feature, a training need, a confusing interface, or a local workflow conflict. Governance should study the pattern rather than punish people for challenging the tool.

Human oversight also requires authority and time. Naming a reviewer is meaningless if dispatch incentives prevent inspection, performance targets reward clearing alerts without diagnosis, or technicians cannot see the evidence. Set service levels by risk, protect capacity for high-consequence cases, and let specialists suspend an alert family. Maintain non-AI diagnostic competence so the organization can challenge the model, operate through outages, and train new staff on mechanical reasoning.

Evidence: nist-ai-rmf, nist-ai-rmf-playbook, doe-om-guide

Backtesting that survives scrutiny

Separate vehicles and time, recreate data availability, and compare decisions at one threshold

Randomly splitting telemetry rows creates leakage because adjacent observations from the same vehicle can land in training and test sets. The model then recognizes a vehicle's history rather than proving it can generalize. Hold out entire vehicles where the use case requires performance on unseen assets, and always reserve later time for a realistic prospective test. If the model is personalized after sufficient history, define a separate evaluation for that workflow rather than mixing it with cold-start claims.

Backtests must recreate what was available at the prediction timestamp. Exclude repair codes, invoices, technician notes, updated component identity, and fault confirmations recorded after the alert time. Apply the historical ingestion delay and missing-data behavior. Version the feature logic and source mappings. A high score built with future information will collapse in production, and the collapse may look like mysterious drift instead of leakage.

Choose the threshold before reading the final holdout and keep it tied to capacity. Compare the predictive policy with the actual mileage/calendar and condition-rule baseline over the same eligible vehicle-time. Count alert episodes, events, and asset exposure, not telemetry rows. Provide uncertainty intervals or repeated cohort estimates where feasible; a result driven by a handful of failures should not be presented with unwarranted precision.

Test subgroups that can change signal behavior: make and model, component revision, age, duty cycle, region, climate, sensor and gateway version, maintenance location, and newly onboarded vehicles. Small groups may support only qualitative review, which should be stated. NIST frames valid and reliable, safe, secure and resilient, accountable and transparent, explainable and interpretable, privacy-enhanced, and bias-managed properties as characteristics of trustworthy AI; the evaluation plan should translate the relevant properties into evidence for this fleet decision.

1. Freeze the target and horizon

   Write the qualifying event, confirmation evidence, prediction timestamp, useful lead-time window, exclusions, and treatment of repeated alerts before model comparison.

2. Create vehicle- and time-safe partitions

   Prevent the same asset's neighboring history and later periods from leaking into evaluation; define a separate cold-start cohort where required.

3. Replay live availability

   Use only data that would have arrived by each timestamp, including real gaps, latency, maintenance updates, and historical interface behavior.

4. Lock the operating threshold

   Select a threshold from training and validation evidence plus shop capacity, then measure the untouched holdout without tuning to its answers.

5. Compare the incumbent

   Apply the same eligibility and outcome rules to current interval and condition policies so incremental alerts and misses are visible.

6. Adjudicate errors

   Have domain reviewers inspect a sample of true and false alerts, misses, and ambiguous labels to distinguish model failure from data or target failure.

Evidence: scania-component-x, nist-ai-rmf, nist-ai-rmf-playbook

Prospective proof

Shadow mode comes before an operational trial, and an operational trial comes before ROI claims

Shadow mode sends predictions to a controlled evaluation log without asking dispatch or maintenance to act. It proves that the intended vehicles are covered, features arrive on time, alerts are deduplicated, evidence is understandable, and model output can be joined to later outcomes. Technicians can review sampled cases without having the alert change the outcome. This stage should span relevant weather, routes, and utilization patterns rather than a convenient short demonstration.

An operational trial begins only after the shadow gate is met. Randomization is ideal when safe and practical, but maintenance interventions can contaminate future labels, and safety obligations always override experimental assignment. Alternatives include phased rollout by depot, matched vehicle cohorts, or stepped-wedge designs, reviewed by appropriate engineering, legal, and safety owners. Predeclare the analysis and record departures rather than selecting the comparison that looks best afterward.

Outcome measures should connect the prediction to maintenance: confirmed conditions, qualifying roadside events, unscheduled downtime, planned versus unplanned work, diagnosis time, repeat repair, part consumption, preventive compliance, and available service days or miles. Financial measures need agreed ledger definitions and treatment of capital, subscription, telematics, integration, training, labor, and change management. Avoid multiplying every alert by an assumed breakdown cost; many alerts would never have become roadside failures.

A pilot can succeed without proving immediate fleet-wide savings. It may establish that one component has a learnable precursor, that data gaps must be fixed, that a transparent rule beats the model, or that the warning horizon is operationally useless. Those are valuable decisions. The expansion gate should require measured incremental value and controlled risk, while the stop gate should make it easy to retire an unhelpful alert family without threatening the larger maintenance program.

Evidence: nist-ai-rmf-playbook, nist-phm-roadmap

Cybersecurity and governance

A maintenance signal can become a vehicle, worker, vendor, and operational-security exposure

Predictive maintenance expands the data path from vehicle networks and gateways through wireless links, vendor clouds, integration services, data stores, model endpoints, mobile devices, and shop systems. Inventory every component, owner, privilege, interface, data class, dependency, and software update path. Separate the ability to read telemetry from the ability to send commands or change vehicle configuration. A maintenance use case rarely needs broad control access, and its architecture should not acquire that power by convenience.

NHTSA's 2022 Cybersecurity Best Practices for the Safety of Modern Vehicles recommends a risk-based, layered approach for the vehicle ecosystem. For a fleet buyer, practical questions include segmentation, authenticated and encrypted communication, least privilege, software and hardware inventory, vulnerability management, logging, incident response, supplier expectations, update integrity, and the ability to contain compromised services. The guidance is non-binding, so it informs design without replacing applicable legal, contractual, or manufacturer requirements.

NIST CSF 2.0 organizes cybersecurity outcomes around Govern, Identify, Protect, Detect, Respond, and Recover, with explicit emphasis on governance and supply chains. Apply that lifecycle to the entire predictive-maintenance service. Know how access is revoked, how anomalous API activity is detected, how a compromised vendor credential is contained, how predictions are suspended, how schedule and rule fallbacks operate, and how historical evidence is preserved for investigation. Test recovery before the platform becomes a dispatch dependency.

Telemetry can also reveal location, routes, work patterns, driving behavior, customer activity, and asset utilization. Define purpose, retention, access, sharing, and deletion with privacy, labor, legal, security, and workforce stakeholders in the relevant jurisdictions. Do not quietly reuse a maintenance dataset for performance scoring or discipline. A cybersecurity program and AI governance register should cover vendors, subprocessors, model versions, data flows, incidents, exceptions, and the person authorized to stop the system.

Evidence: nhtsa-vehicle-cyber, nist-csf-2, nist-ai-rmf

Build, buy, or combine

Compare ownership of evidence and workflow before comparing model brands

An OEM offering may have deep component knowledge and native signals but cover only its equipment and approved service network. A telematics provider may offer broad connectivity and fleet dashboards while depending on available parameter mappings. A maintenance software provider may own work orders and parts context but receive sparse vehicle data. A specialist predictive vendor may bring modeling depth yet require extensive integration and label adjudication. A custom layer can unify mixed fleets but transfers more engineering and operational responsibility to the carrier.

Ask who owns raw and derived data, how it can be exported, how long it is retained, and whether historical records remain available after termination. Inspect coverage by VIN, model year, gateway, component, country, and firmware—not merely a logo wall. Require the exact prediction target, supported warning horizon, exclusions, update cadence, alert deduplication, evidence display, technician feedback flow, and measured performance on a relevant cohort. A vendor benchmark on a proprietary population is context, not proof for the buyer's fleet.

Commercial evaluation should include telematics hardware, connectivity, installation, calibration, platform subscription, data egress, storage, integration, identity resolution, work-order changes, model validation, cybersecurity review, training, technician diagnosis, support, and exit. Compare these costs with the marginal use case, not with all maintenance spending. If one model targets one component on one subgroup, its addressable events and benefits are limited accordingly.

Architecture should preserve optionality. Use stable asset, event, feature, alert, disposition, and work-order interfaces; keep raw evidence where contracts permit; and store the decision record outside a vendor-only dashboard. A custom-software layer can be justified when it owns fleet-specific workflow and interoperability, while prediction remains replaceable. The goal is not maximum insourcing. It is the ability to audit, change, suspend, and exit without losing the maintenance history.

Evidence: gsa-vehicle-guide, nist-ai-rmf, nhtsa-vehicle-cyber, nist-csf-2

System design

Connect vehicle evidence to maintenance action through versioned, reversible services

A practical architecture starts with an asset registry that resolves VIN, unit, component, trailer, gateway, configuration, ownership, and service history. An ingestion layer records source timestamps, arrival timestamps, units, signal definitions, quality flags, and gaps. It should retain sufficient raw or minimally transformed evidence under an explicit policy so analysts can reproduce an alert when feasible. Normalization must not erase vendor-specific meaning or pretend every parameter is comparable.

The decision layer should keep schedules, deterministic rules, and models separately versioned. A feature service calculates only from data available at the decision time. The model registry ties artifacts to training data, code, configuration, evaluation, approvals, and applicable population. A policy service converts scores into no action, monitor, diagnostic review, expedited inspection, or escalation while enforcing hard maintenance constraints and location capacity.

The workflow layer creates or enriches a work item, preserves the alert episode, records who viewed it, and captures disposition plus evidence. Integration with computerized maintenance management, dispatch, inventory, warranty, and procurement systems should be idempotent and observable; duplicated alerts must not create duplicate parts orders or work. When an integration fails, the system needs a queue, ownership, retry behavior, and manual fallback rather than silently dropping a safety-relevant review.

The monitoring layer covers data coverage and freshness, schema and firmware change, feature drift, score distribution, alert volume, cohort performance, technician response, failure outcomes, security events, and service health. Model monitoring without workflow monitoring is incomplete. A score can remain statistically stable while every alert waits unreviewed. Likewise, a data feed can look healthy while a component mapping changed. Design quality assurance around the whole decision path from vehicle observation to closed maintenance record.

Evidence: nist-ai-rmf-playbook, nist-csf-2, scania-component-x

Implementation sequence

Move from maintenance control to one production use case in eight gated steps

A staged program prevents a fleet from paying for broad connectivity and model licenses before it knows which decision will improve. Each gate should leave a usable artifact even if the AI case stops: a cleaner asset register, better failure taxonomy, stronger interval baseline, more structured technician feedback, tested security controls, or a reproducible evaluation set. That makes disciplined discovery an operating investment rather than a prelude that only has value if a vendor is selected.

The sequence below is deliberately narrower than a fleet-wide transformation. Start with one failure mode and coherent population, then expand only after prospective evidence. Parallel work is appropriate for data, shop design, and security, but gate ownership must remain clear. A steering group should include fleet maintenance, technicians, safety, operations, data, IT, security, finance, procurement, legal or privacy as relevant, and the asset or component engineering expertise required for the target.

1. Baseline maintenance control

   Audit due policies, preventive compliance, inspections, defect closure, asset identity, work-order causality, downtime, and roadside-event coding. Repair material gaps before attributing them to prediction.

2. Select one failure mode

   Use consequence, recurrence, observable precursor, action horizon, parts and shop feasibility, and evidence volume to choose a bounded target and vehicle cohort.

3. Build the adjudicated timeline

   Join telemetry, configuration, inspections, work orders, parts, and outcomes with source and event times; have domain reviewers resolve a representative label sample.

4. Benchmark simple controls

   Evaluate current intervals, a duty-cycle-adjusted interval, and transparent condition rules before accepting the additional burden of a learned model.

5. Run leakage-safe model evaluation

   Compare candidate approaches on vehicle- and time-separated data using predeclared event, horizon, threshold, capacity, lead-time, and cohort metrics.

6. Complete safety, cyber, privacy, and vendor gates

   Threat-model the data path, constrain privileges, document human authority and hard controls, validate contracts and exports, and test fallback, rollback, and incident response.

7. Operate in shadow mode

   Generate live timestamped alert packets without changing maintenance, measure coverage and latency, sample technician interpretation, and confirm the predicted workload fits the shop.

8. Conduct a bounded trial and decide

   Activate the workflow for an approved cohort, monitor maintenance and guardrail outcomes, adjudicate errors, account for full costs, and expand, revise, revert to rules, or stop.

Evidence: nist-ai-rmf, nist-ai-rmf-playbook, nhtsa-vehicle-cyber, fmcsa-systematic-guidance

Failure-mode audit

Most predictive-maintenance failures are operating-system failures wearing a model label

The first common failure is target ambiguity. Teams train on any repair or dashboard fault and later speak about roadside-breakdown prevention. Those outcomes differ. Remedy it by naming one event, confirmation evidence, exclusions, horizon, and action. The second is leakage: post-repair information enters features or the same vehicle appears on both sides of a random split. Remedy it with event-time reconstruction, vehicle separation, and a later holdout.

The third failure is label drift. A parts campaign, new diagnostic policy, warranty change, or technician coding initiative changes what counts as a recorded event. The model's apparent performance can move even if mechanical behavior does not. Monitor the recording process, not only sensors. Keep policy and coding changes in the event timeline and re-adjudicate samples across periods.

The fourth failure is alert saturation. A threshold chosen to maximize recall generates more cases than the shop can inspect, false positives linger, and technicians learn to dismiss the system. Cap launch volume, prioritize by consequence and evidence, track queue age, and suspend an alert family when review capacity or precision falls below the agreed gate. A silent dashboard is not oversight.

The fifth failure is intervention blindness. Once an alert causes a repair, the failure that might have occurred is no longer observable. Treating every preventive intervention as a proven true positive inflates performance; treating it as a negative punishes useful action. Preserve diagnostic confirmation, use engineering adjudication, and design prospective analysis for this censoring. Never claim avoided breakdowns simply by counting alerts followed by replacement.

The sixth failure is fleet change. New model years, component suppliers, fuels, routes, payloads, firmware, gateways, and service networks alter signal and outcome distributions. Apply eligibility rules, detect unknown configurations, monitor cohorts, and fall back to schedule and rules until evidence supports coverage. Expansion to a new asset family is a new validation decision, not a checkbox.

The seventh failure is vendor or cyber dependency. An expired certificate, API change, cellular outage, compromised account, or cloud incident can halt data or corrupt trust. Exercise offline and manual maintenance continuity, credential revocation, incident communication, and recovery. A predictive layer that prevents the fleet from knowing what service is due during an outage has weakened the baseline it was meant to improve.

Evidence: nist-ai-rmf-playbook, nhtsa-vehicle-cyber, nist-csf-2, scania-component-x

Economics without theater

Build a component-level total-cost model and reconcile it to the ledger

The financial model should begin with eligible assets and target-event incidence, not total fleet maintenance expense. Estimate or measure how many events the model can observe, how many arrive inside the useful window at the chosen threshold, and how many lead to a confirmed, changed action. Separate improved diagnosis, planned repair, bundled service, avoided collateral damage, and service recovery. Do not treat every alert as an avoided tow or every component replacement as a prevented failure.

Cost inputs include hardware, installation, cellular service, platform subscription, data access, integration, storage, validation, security, workflow development, technician training, alert review, additional inspections, parts, warranty effects, support, and program ownership. Opportunity cost includes bays occupied by no-fault-found work and preventive tasks displaced by alert volume. Benefits can include measured reductions in qualifying roadside events, unplanned downtime, emergency labor, and repeat diagnosis, plus better parts or service scheduling when directly evidenced.

Use ranges for uncertain inputs and show the break-even conditions: required precision, useful-horizon recall, event incidence, action conversion, and per-event net value. Recalculate with actual pilot data and reconcile costs to invoices and labor records. Report costs per eligible asset-month and per confirmed intervention; report outcome costs per available mile or service day only with consistent definitions. Finance should be able to reproduce the result without reading model code.

The BTS VIUS reports substantial variation in annual use between truck tractors and other heavy trucks, reinforcing why annual per-vehicle assumptions must be cohort-specific. FHWA reports that trucks carried 13.1 billion tons and $18.3 trillion of domestic freight in 2023, which demonstrates the importance of trucking to freight movement. It does not establish the value of this software or the cost of a breakdown. Use public scale figures for context and the carrier's own operational ledger for the investment decision.

Evidence: bts-vius-summary, fhwa-highways-2026

Safety and inspection evidence

Roadside data should guide priorities without being mistaken for a random failure sample

FMCSA's national roadside-inspection report for calendar 2024 records 1,973,187 vehicle inspections at the included levels and 453,460 inspections with a vehicle out-of-service violation, a total vehicle out-of-service rate of 22.98 percent in that report. This is material enforcement evidence, but it is not a random survey of every commercial vehicle and it is not a breakdown rate. Inspections, selection, levels, vehicle mix, and violation definitions shape the result.

For predictive-maintenance planning, the data supports a disciplined question: which inspection and defect categories appear in the carrier's own operation, and which can be reduced by better inspection, repair, interval, rule, or prediction? Some visible defects belong in driver and shop inspection rather than remote analytics. Some develop through measurable wear. Some have electronic signals, while others do not. The method should follow the failure mechanism, not the availability of a fashionable model.

The current FMCSA SMS methodology calculates the Vehicle Maintenance measure from time- and severity-weighted applicable violations over relevant inspections and adds weight for out-of-service conditions. It is designed to prioritize carrier safety interventions, not validate a predictive algorithm. A carrier can nevertheless monitor its underlying inspection results, defect closure, and maintenance controls as guardrails. Model performance should never be celebrated while roadworthiness indicators deteriorate.

Use public inspection data with dated snapshots and scope notes. FMCSA states that its displayed MCMIS information is subject to updates as additional information is reported. Preserve the extract used for a decision and avoid presenting the latest dashboard value as an immutable fact. The same version discipline should apply internally to work orders, fault mappings, model scores, and adjudicated outcomes.

Evidence: fmcsa-oos-report, fmcsa-sms-methodology

Operating cadence

Govern the model like a maintenance policy that can change work on real equipment

Daily operations need an alert triage owner, queue-age targets, escalation by consequence, data-health checks, and a clear path when evidence is missing. Weekly review should examine alert episodes, dispositions, false-alert themes, missed known events, parts and bay constraints, preventive work at risk, and integration failures. Monthly governance can review cohort metrics, roadside and defect guardrails, overrides, security events, vendor changes, and whether the threshold still matches capacity.

Every model, rule, feature mapping, and policy release needs an effective date, applicable population, approvers, validation evidence, change note, and rollback. Do not update a model and threshold simultaneously without being able to distinguish their effects. When a vendor changes signal normalization or an OEM deploys firmware, open a change assessment. Unknown or unsupported configurations should route to the baseline rather than receive an invented score.

Define suspension triggers before launch: data freshness breach, alert spike, precision deterioration, missed high-consequence pattern, unexplained cohort disparity, evidence-interface failure, compromised credential, vendor incident, or inability of the shop to review the queue. Suspension should stop new model-driven action while preserving required schedules, inspections, defect workflows, and approved rules. Practice the switch so it is an ordinary control rather than a crisis improvisation.

Quarterly or release-based reviews should revisit the failure-mode register and business case. A component revision may remove the problem; an improved OEM diagnostic may make the model redundant; a part shortage may change the useful horizon; a shop redesign may change capacity. Mature governance is willing to retire a once-useful model. The objective is controlled asset availability and safe operation, not permanent use of AI.

Evidence: nist-ai-rmf, nist-ai-rmf-playbook, nist-csf-2, ecfr-3963

Final branch

Choose baseline, rules, pilot, or scale with an explicit go/no-go record

Choose a strengthened mileage and calendar baseline when the failure is adequately controlled by transparent intervals, labels and identities are weak, sensors do not observe deterioration, events are too few for defensible evaluation, or the operation cannot investigate alerts. This is not falling behind. It is refusing to purchase inference before the decision can be measured. Improve segmentation, defect closure, and work-order quality, then reassess.

Choose condition rules when engineering or diagnostic evidence identifies a stable signal and response. Rules are particularly strong when rapid explanation, immediate deployment, and limited failure data matter. Validate their alert load and outcome, keep versions and applicability explicit, and compare any later AI model against them. The best benchmark for a sophisticated model may be a well-designed three-line rule.

Choose a predictive pilot when one consequential failure mode has enough adjudicated events, advance signals, useful warning time, eligible vehicles, technician ownership, shop capacity, security controls, and a leakage-safe evaluation showing incremental value over schedule and rules. Keep the pilot bounded and reversible. Do not purchase fleet-wide outcomes from a component-level test.

Scale only when prospective operation confirms coverage, alert utility, technician adoption, maintenance outcomes, full costs, and guardrails across relevant cohorts and seasons. Expand by component and population, repeating the validation and cyber review when the data-generating process changes. If results are inconclusive, extend only for a predeclared evidence gap; do not turn uncertainty into an endless pilot.

The durable answer is comparison-led: mileage and calendar controls provide an auditable safety net, condition rules capture known state, and AI searches for useful advance patterns. Each must prove its place against the others. A carrier that protects the baseline, respects technicians, measures rare events honestly, and can suspend the model is more AI-ready than one with a hundred health scores and no reproducible maintenance decision.

Evidence: fmcsa-systematic-guidance, nist-ai-rmf, nist-phm-roadmap, nhtsa-vehicle-cyber