Architecture details

Amazon Redshift stores vehicle telemetry data from connected fleets, with AWS Lambda querying tire pressure readings hourly via Redshift Data API, while AWS Glue ETL jobs transform raw sensor data into standardized formats for downstream processing.

AWS Glue processes telemetry through parallel pipelines: the ML ETL prepares features for model training, while the Root ETL validates and enriches sensor readings, with both pipelines storing intermediate results in Amazon S3 using Parquet format for efficient columnar analytics.

Amazon SageMaker trains Random Cut Forest anomaly detection models weekly on historical tire pressure patterns, with SageMaker Batch Transform running daily inference to generate anomaly scores that predict tire failures 7-14 days in advance.

AWS Step Functions orchestrates the ML workflow from data validation through feature engineering, model training, evaluation, and deployment, while Amazon EventBridge schedules training runs weekly and inference jobs daily to maintain prediction accuracy.

A parallel filter-based pipeline uses statistical analysis to detect rapid pressure drops exceeding 2 PSI per hour, calculating leak rates through time-series regression and cross-referencing results with ML predictions for validation.

Amazon DynamoDB tracks alert state to prevent duplicate notifications, while AWS Lambda consolidates predictions from both ML and filter pipelines, assigns severity levels based on pressure drop rates, and delivers alerts to fleet management systems via REST API or Amazon SNS.

Amazon API Gateway provides real-time access to prediction data and alert history, enabling integration with dealer management systems, mobile apps, and customer notification workflows with sub-second latency.

Data Source Configuration

The reference implementation in guidance-for-predictive-maintenance/ accesses fleet telemetry via two approaches — choose the one that fits your existing Redshift architecture:

Redshift Datashare Approach:

Alternative S3 Unload Approach:

Data Schema:

Root ETL Pipeline

The Root ETL pipeline ingests, processes, and prepares telemetry data for both ML and filtering approaches.

Step 1: Data Ingestion

CloudWatch Events Rule: query-cron-job

Lambda Function: redshift-query-lambda

Query Logic:

SELECT
  aaid,
  tpms_avmtireposition AS tire_position,
  tpms_avmtirepressure AS tire_pressure,
  tpms_avmtiretemperature AS tire_temperature,
  event_timestamp,
  odometer,
  vehicle_make,
  vehicle_model
FROM redshift_datashare.tire_telemetry
WHERE event_timestamp >= CURRENT_TIMESTAMP - INTERVAL '1 hour'
  AND event_timestamp < CURRENT_TIMESTAMP
ORDER BY aaid, event_timestamp

Output:

Step 2: Data Transformation

CloudWatch Events Rule: etl-cron-job

AWS Glue Job: root-etl-pipeline

Transformation Steps:

Output:

Machine Learning Approach

The ML approach uses unsupervised anomaly detection with Amazon SageMaker’s Random Cut Forest algorithm.

ML ETL Pipeline

Step Function: ml-etl-pipeline

Step 1: Determine Paths

Step 2: Feature Engineering

Processing Stages:

Output:

ML Training Pipeline

Step Function: ml-training-pipeline

Steps:

Hyperparameters:

{
  "num_trees": 100,
  "num_samples_per_tree": 256,
  "feature_dim": 25,
  "eval_metrics": ["accuracy", "precision", "recall"]
}

Training Data:

Model Evaluation:

ML Inference Pipeline

Step Function: ml-inference-pipeline

Steps:

Transform Configuration:

Processing Logic:

def process_predictions(raw_predictions):
    # Add CSV headers back
    predictions_df = add_headers(raw_predictions)

    # Determine anomaly based on score threshold
    predictions_df['is_anomaly'] = predictions_df['anomaly_score'] > 0.75

    # Calculate time to reach 80 PSI (critical threshold)
    predictions_df['time_to_80_psi'] = calculate_time_to_threshold(
        current_pressure=predictions_df['tire_pressure'],
        leak_rate=predictions_df['leak_rate'],
        threshold=80
    )

    # Classify severity
    predictions_df['severity'] = classify_severity(
        anomaly_score=predictions_df['anomaly_score'],
        time_to_80_psi=predictions_df['time_to_80_psi']
    )

    return predictions_df

Severity Classification:

Output:

Filtering Approach

The filtering approach uses a stepwise filter-based algorithm to identify gradual tire leaks without machine learning.

Core Algorithm

Purpose: Detect slow tire leaks that might not be immediately apparent

Process:

Data Processing Pipeline

Step Function: filtering-pipeline

Lambda Function: filtering-algorithm

Algorithm Steps:

Filtering and Aggregation

Deduplication:

Aggregation:

Scheduling

CloudWatch Events Rule: filtering-schedule

Alerts Approach

Both ML and filtering approaches generate alerts that integrate with maintenance scheduling systems.

Alert Generation

S3 Event Notification:

Lambda Function: generate-alerts

Alert Logic:

Alert Format

Relay Garage System Format:

{
  "alert_id": "uuid",
  "aaid": "vehicle-12345",
  "tire_position": "front_left",
  "alert_type": "tire_leak",
  "severity": "high",
  "leak_rate": -1.2,
  "current_pressure": 28.5,
  "time_to_80_psi": 9,
  "recommendation": "Schedule tire inspection within 7 days",
  "source": "ml_model",
  "confidence": 0.92,
  "timestamp": "2026-01-28T12:00:00Z"
}

Alert Delivery

Amazon SNS Topic: tire-alert-notifications

Subscriptions:

Amazon API Gateway: alerts-api

Amazon DynamoDB Table: tire-alerts

Alert Status Tracking

Status Values:

Update Mechanism:

Deployment Architecture

Infrastructure as Code: AWS CDK (Python)

The reference implementation deploys six CDK stacks — a Data stack (S3 buckets, Glue databases), an ETL stack (Glue jobs, Lambda functions, CloudWatch Events), an ML stack (SageMaker training, batch transform, Step Functions), a Filtering stack (Lambda functions, Step Functions), an Alerts stack (SNS topics, API Gateway, DynamoDB), and a Monitoring stack (CloudWatch dashboards and alarms). This structure is illustrative of how you might organize a CDK application for this pattern; your implementation may combine or split concerns differently.

Cost Estimate:

Data Source: Redshift Datashare Pattern

The reference implementation uses Redshift Datashare for cross-account access to existing fleet telemetry. This section describes the pattern and the key architectural tradeoff.

Why Redshift Datashare vs. S3 Unload:

Redshift Datashare allows the predictive maintenance account to query the source telemetry cluster directly, without the source account setting up and scheduling UNLOAD jobs. The tradeoff is that Datashare requires a one-time manual permission grant in the source cluster, whereas S3 unload requires no cross-account Redshift configuration but does require scheduling and managing the UNLOAD jobs on the source side.

For most fleet architectures where the telemetry Redshift cluster is already managed by a separate team, Datashare provides a lower-friction integration path once the initial grant is in place. S3 unload is the better fit when the source team cannot grant Datashare access or when data volumes are very high.

Datashare setup pattern (source account):

The source account creates a datashare for the tire telemetry tables, adds the relevant schema and tables to the share, and grants usage to the consumer account. The consumer account then creates a local database from the datashare reference. Replace <source-account-id> and <consumer-account-id> with your actual account IDs:

-- In the source Redshift cluster
CREATE DATASHARE tire_telemetry_share;
ALTER DATASHARE tire_telemetry_share ADD SCHEMA public;
ALTER DATASHARE tire_telemetry_share ADD TABLE public.tire_telemetry;
ALTER DATASHARE tire_telemetry_share ADD TABLE public.vehicle_metadata;
-- Grant usage to the consumer account
GRANT USAGE ON DATASHARE tire_telemetry_share TO ACCOUNT '<consumer-account-id>';

-- In the consumer account (where the solution is deployed)
CREATE DATABASE tire_telemetry_db FROM DATASHARE tire_telemetry_share
OF ACCOUNT '<source-account-id>' NAMESPACE '<source-namespace>';
-- Grant permissions to the Lambda execution role
GRANT USAGE ON DATABASE tire_telemetry_db TO IAM_ROLE 'arn:aws:iam::<consumer-account-id>:role/predictive-maintenance-lambda-execution-role';
GRANT SELECT ON ALL TABLES IN SCHEMA public TO IAM_ROLE 'arn:aws:iam::<consumer-account-id>:role/predictive-maintenance-lambda-execution-role';

S3 Unload alternative:

If using S3 unload instead of Datashare, configure Redshift to UNLOAD data to the S3 raw bucket hourly, remove the redshift-query-lambda from the deployment, and update the root-etl-pipeline Glue job to read from S3 directly.