Nuevas Builds a GenAI-Powered Predictive Maintenance Platform on AWS to Plan Fleet Maintenance Before Breakdowns Occur
Nuevas partnered with Minutus Computing to build a predictive-maintenance platform on AWS — one that streams OBD-II / CAN bus telemetry from commercial fleet vehicles, detects developing faults with rules and machine-learning anomaly scoring, explains each finding in plain language with Amazon Bedrock, and drafts maintenance work orders, with dispatchers and maintenance staff still deciding every repair, schedule and vehicle restriction.
One view of vehicle health, from raw telemetry to a reviewed work order
Nuevas Technologies runs a commercial vehicle fleet whose dispatchers, maintenance planners and workshop teams depend on knowing which vehicles are healthy and which need attention. Vehicle gateways report timestamped OBD-II / CAN bus data — diagnostic trouble codes, engine temperature, battery signals, vibration where available, mileage and GPS. The platform serves four groups of users — dispatchers, maintenance planners, workshop staff and platform administrators — through an existing fleet-management system or an optional operations portal.
To move from reactive repairs to planned maintenance without handing control to automation, Nuevas Technologies engaged Minutus Computing, an AWS partner specializing in AI/ML platform solutions for enterprise clients, to design a GenAI-powered predictive-maintenance platform on AWS. Telemetry is ingested through AWS IoT Core and Amazon Kinesis Data Streams, rules and Amazon SageMaker AI models detect developing faults, and Amazon Bedrock turns each verified health event into a plain-language explanation and a draft work order — grounded in the evidence and, where available, in approved service manuals, and always reviewed by people before anything consequential happens.
The design is secured from the first day of the engagement, built to treat lost vehicle connectivity as normal, and costed per vehicle so that spend stays visible as the fleet grows.
Faults surfaced late, in a form that was hard to act on
Maintenance at Nuevas Technologies was largely reactive. Vehicle faults were noticed only after performance deteriorated or a vehicle broke down, and the information that could have warned the team earlier was technical, scattered and slow to turn into action.
Late fault discovery
Faults were noticed after performance deteriorated or a breakdown occurred, causing roadside breakdowns, route disruption and unplanned workshop visits.
Hard-to-read diagnostics
Raw diagnostic codes and telemetry did not clearly explain operational priorities, so dispatchers and planners spent time interpreting signals or risked missing them.
Disconnected context
Vehicle health data, route plans and workshop availability were considered separately, making maintenance planning reactive and prioritization inconsistent.
Manual searching and drafting
Workshop teams searched service manuals and prepared work orders by hand, which slowed triage and made work-order quality inconsistent.
Trust in alerts
Unconfirmed anomalies risked being treated as confirmed failures, leading to unnecessary downtime or a loss of trust in alerts.
Intermittent connectivity
Vehicles connect over mobile networks that are intermittent by nature, so any platform had to treat temporary loss of connectivity as normal and avoid mistaking silence for either a healthy or a faulty vehicle.
Data protection and no KPI baseline
Vehicle, location and driver data had to be encrypted and available only to authorized roles, and metrics such as time to detect, breakdown frequency and false-positive rate were not systematically tracked.
No cost visibility
Usage-based costs for device messaging, streaming, inference, generative AI and storage could not be attributed to fleets, depots or processing stages, and no cost per vehicle had been established, making spend hard to forecast as the fleet grows.
Rules, machine learning and GenAI working together, with people in charge
Minutus Computing designed a serverless, streaming platform on AWS. Vehicle gateways publish telemetry to AWS IoT Core over TLS with per-device identities; Amazon Kinesis Data Streams buffers events and AWS Lambda validates, normalizes and enriches them. Threshold rules and Amazon SageMaker AI anomaly scoring run side by side, so known limits are always enforced while unusual patterns are also caught. When a result warrants review, a health event is created and Amazon Bedrock explains it from that verified record — optionally grounded in approved service manuals through Amazon Bedrock Knowledge Bases and constrained by Amazon Bedrock Guardrails — and drafts a proposed work order.
Telemetry Ingestion
Timestamped OBD-II / CAN bus data arrives through AWS IoT Core with per-device X.509 identities, and is buffered and validated for device identity, timestamps, missing values and duplicates.
Context & Detection
Records are normalized across makes and models and enriched with vehicle, trip and service-history context; threshold rules and Amazon SageMaker AI anomaly scoring flag developing faults.
Explanation
Amazon Bedrock produces a structured, plain-language explanation of the observed signals, likely causes to investigate and data-quality limitations, describing an anomaly as a potential fault rather than a confirmed failure.
Work-Order Drafting
A proposed work order is drafted with vehicle details, evidence, a suggested priority and manual references; nearby-workshop context can be added with Amazon Location Service.
Alerting & Review
Amazon EventBridge and Amazon SNS route qualifying events to the responsible team, and dispatchers or maintenance staff review and approve before repairs are scheduled or a vehicle is restricted.
Continuous Improvement
Confirmed repair outcomes and false-positive feedback tune rules, prompts and models under governance, with historical data retained in Amazon S3 and queried with Amazon Athena.
People stay in control throughout: explanations and draft work orders are recommendations, every consequential action is approved by authorized staff, and the decisions to repair, schedule, restrict or withdraw a vehicle are never automated.
Vehicle devices connect to the AWS IoT Core endpoint over MQTT with TLS and mutual authentication. Processing workloads that run in a VPC are deployed in private subnets across two Availability Zones, and VPC endpoints give private connectivity to Amazon S3, Amazon DynamoDB, Amazon Kinesis Data Streams, Amazon Bedrock and Amazon SageMaker AI.
Amazon DynamoDB holds the latest vehicle health, anomaly results and work-order status; Amazon API Gateway exposes the APIs consumed by an existing fleet platform, or by an optional portal on Amazon ECS behind an Application Load Balancer. A security and governance layer (AWS IAM, AWS Organizations, AWS Secrets Manager, AWS KMS, AWS Config, AWS CloudTrail) and an observability layer (Amazon CloudWatch and Amazon SNS) wrap the environment.
Shift-left: security decisions made before the first vehicle connects
Security is part of the platform’s design rather than a step added at release. AWS security best practices are shared with the Nuevas Technologies team at the start of the engagement through a security best-practice document and a knowledge-transfer session, and the decisions below are applied in lifecycle order.
Threat modeling first
Security and privacy requirements are captured with the functional requirements; vehicle, location and driver data are classified, and a threat model covering device spoofing, telemetry tampering, data exposure and GenAI-specific threats such as prompt injection is reviewed before build starts.
Foundations before workloads
Root-account restrictions, MFA, AWS Organizations service control policies, AWS CloudTrail in all regions and least-privilege AWS IAM roles with short-lived credentials are in place before anything is deployed.
Device identity by design
Per-device X.509 identities, device-scoped IoT policies that allow publishing only to a device’s own topics, a certificate rotation and revocation plan, and AWS IoT Device Defender audit rules are designed before devices are connected.
Secure code and pipeline
Secret scanning, dependency scanning, static analysis and peer review run on every commit and pull request, Amazon Inspector scans Lambda code and dependencies, and credentials come from AWS Secrets Manager — never from code or prompts.
Policy-checked infrastructure as code
Network, IAM, KMS, S3, IoT and Bedrock settings are defined as code, version-controlled and checked against policy rules before deployment, while AWS Config continuously evaluates deployed resources in both regions.
GenAI and ML safety gates
Prompts, Amazon Bedrock Guardrails and model versions are version-controlled and must pass an evaluation suite — including prompt-injection, unsupported-claim and personal-data tests — before promotion; Bedrock model access is limited to approved models, and ML artifacts are promoted through Amazon SageMaker AI Model Registry only after approval.
Data protection by default
AWS KMS encryption is enabled on every data store, access is limited by bucket policies and IAM, traffic stays on the private network path through VPC endpoints, and lifecycle rules enforce retention.
Release and operate
The same controls apply in Dev, Test and Prod; Blue-Green or Canary releases, including shadow-mode runs of new models and prompts, validate changes on a small share of live traffic; and Amazon GuardDuty, AWS Security Hub, periodic access reviews, penetration testing and a tested incident-response process keep security part of daily operations.
The building blocks
| Capability | AWS Service(s) | Role in the Solution |
|---|---|---|
| Device connectivity | AWS IoT CoreAWS IoT Device DefenderAWS IoT Jobs | Receives MQTT telemetry over TLS with mutual authentication, restricts each device to its own topics, detects misbehaving or compromised devices and rolls out updates to vehicles in rate-limited groups. |
| Streaming & processing | Amazon Kinesis Data StreamsAWS Lambda | Buffers telemetry, then validates, normalizes, enriches and applies threshold rules in near real time, scaling with message rate. |
| Anomaly detection | Amazon SageMaker AI | Trains, deploys and runs anomaly-scoring models on windowed features to detect deviations from expected or historical behavior. |
| GenAI explanations & work orders | Amazon Bedrock | Generates evidence-grounded, plain-language explanations and draft work orders from the verified health-event record. |
| Maintenance knowledge (RAG, optional) | Amazon Bedrock Knowledge BasesAmazon S3 | Retrieves approved service-manual content, filtered by make, model, year and system, so suggested checks and manual references follow approved procedures. |
| GenAI safety | Amazon Bedrock Guardrails | Applies content filters, denied topics and prompt-attack protections to reduce unsafe or out-of-scope output, alongside mandatory human approval. |
| Alerting & workflow | Amazon EventBridgeAmazon SNSAmazon SQS | Routes qualifying events, notifies the responsible team, and holds failed work in dead-letter queues for retry. |
| Data & analytics | Amazon S3Amazon DynamoDBAmazon AthenaAmazon QuickSight (optional) | Retains raw and curated telemetry, holds latest vehicle state and work-order status, and supports investigation queries and dashboards. |
| Location context (optional) | Amazon Location Service | Adds nearby-workshop context to maintenance recommendations. |
| Application & API | Amazon API GatewayAmazon ECSApplication Load Balancer | Exposes APIs to an existing fleet platform or hosts the optional operations portal. |
| Identity & governance | AWS IAMAWS OrganizationsAWS STSAWS Secrets Manager | Enforces least-privilege, role-based access with short-lived credentials and keeps device and application secrets out of code. |
| Encryption | AWS KMS | Encrypts telemetry, model artifacts, knowledge-base data and logs at rest, consistently in both regions. |
| Network & edge protection | Amazon VPCVPC endpointsSecurity groupsNetwork ACLsAWS WAFAWS Shield StandardAmazon Route 53 | Keeps processing in private subnets, provides private service connectivity, shields public endpoints and steers traffic. |
| Security & compliance | AWS ConfigAWS CloudTrailAmazon GuardDutyAWS Security HubAmazon InspectorAmazon Macie (optional) | Evaluates configuration continuously, records API activity, detects threats, scans Lambda code and dependencies, and discovers sensitive data. |
| Infrastructure as code & release | AWS CloudFormationAWS CDK or TerraformGit-based CI/CD pipeline | Provisions both regions from the same version-controlled templates and promotes changes through Dev, Test and Prod with rollback to the last known-good version. |
| Monitoring & observability | Amazon CloudWatchAmazon SNS | Provides metrics, logs, alarms and dashboards for ingestion, stream lag, model endpoints, Bedrock and notification delivery. |
| Disaster recovery | Amazon Route 53S3 Cross-Region ReplicationAmazon DynamoDB replication/backupsAWS BackupAWS Secrets Manager replicas | Enables cross-region failover and scheduled backup and restore for business continuity. |
| Cost management | AWS BudgetsAWS Cost ExplorerAWS Cost Anomaly DetectionAWS Compute Optimizer | Attributes spend to fleets and stages, tracks it against per-vehicle cost baselines, flags unexpected spikes and right-sizes compute. |
Designed for vehicles that drop offline and regions that occasionally do too
The platform assumes connectivity will sometimes be lost. Because vehicles connect over mobile networks, temporary loss of vehicle connectivity is treated as a normal operating condition rather than an exception. The network is designed to stay resilient in four situations:
| Scenario | Design response |
|---|---|
| DDoS attacks | Only two entry points face the internet: the AWS IoT Core device endpoint, which rejects unauthenticated clients at connection time through mutual TLS, and — where the optional portal is used — Amazon API Gateway or the Application Load Balancer, filtered by AWS WAF. AWS Shield Standard absorbs infrastructure-layer attacks, and AWS IoT Device Defender detects misbehaving or compromised devices, which are contained by revoking the certificate or detaching the IoT policy. A runbook defines detection, escalation and mitigation. |
| Unexpected increase in traffic | AWS IoT Core, Amazon Kinesis Data Streams, AWS Lambda, Amazon EventBridge and Amazon SNS scale with message rate, and Kinesis capacity, Lambda concurrency and SageMaker AI endpoint scaling are sized from pilot measurements to absorb shift starts and post-outage reconnection bursts. Ingestion is decoupled from scoring, explanation and notification, Amazon Bedrock is invoked only for qualifying events, and service quotas are verified in advance. A runbook covers scaling and throttling review. |
| Loss of connectivity | Gateways buffer telemetry locally and resend it on reconnection using MQTT QoS 1 and persistent sessions, with exponential back-off and jitter; Kinesis retention provides a replay window; and last-seen time marks health status as stale, so silence is never mistaken for a healthy or faulty vehicle. A multi-AZ design absorbs the loss of a zone, Amazon Route 53 health-check failover handles a regional disruption, and calls to SageMaker AI, Bedrock and Location Service use retries, queues and dead-letter queues, and fall back to rule-based alerts. |
| Connectivity removed by misconfiguration | VPC, subnet, security-group, endpoint and IoT Core configuration is defined as code, version-controlled and promoted through Dev, Test and Prod, so every change is reviewed and can be rolled back to the last known-good version. IoT policy changes are validated before deployment, AWS Config evaluates drift continuously, and device-certificate expiry is monitored so identities are rotated before devices are locked out. |
Resilience to traffic growth also depends on limiting how much traffic the platform generates. Reporting intervals are agreed with Nuevas Technologies so that the signals needed by the rules and anomaly models are preserved.
Report by exception
Gateways send a reading when it changes beyond an agreed tolerance or crosses a threshold, with a lower-rate heartbeat otherwise; reporting can be raised temporarily for a vehicle under investigation.
Batch and compact
Readings are grouped into batched messages with compact payloads and published to reserved AWS IoT Core Basic Ingest topics that bypass the publish/subscribe broker.
Reconnect gently
After an outage, gateways send diagnostic trouble codes and safety-relevant events first, then backfill older readings at a limited rate with jittered reconnection; firmware and configuration updates roll out in rate-limited groups through AWS IoT Jobs.
Process once
Sequence identifiers let retransmissions be discarded and repeated events de-duplicated per vehicle, and Amazon SageMaker AI scores windowed features rather than every message.
Call GenAI sparingly
Amazon Bedrock is invoked only for qualifying health events, with scoped prompt context, retrieval filtered by make, model and system, and cached manual passages for frequent fault-code combinations.
Keep traffic private and bounded
VPC endpoints keep service traffic off NAT gateways and the public internet, while per-device limits, Lambda reserved concurrency and bounded auto scaling stop a faulty device or a surge from growing without limit.
When connectivity is lost, the platform team follows an eight-step procedure — detect, notify, scope, contain, remediate misconfiguration, fail over, validate and review — supported by rehearsed playbooks for eight situations: loss of connectivity for a vehicle or group of vehicles; reconnection bursts; loss of an Availability Zone; streaming or processing disruption; Amazon Bedrock or SageMaker AI being unreachable; DNS, edge or certificate failure; misconfiguration; and regional disruption. Dispatchers and planners are told which vehicles’ health status may be stale, and every incident ends with a post-incident review that updates runbooks, alarms and infrastructure templates.
Mirrored DR network
The standby region mirrors the primary region’s VPC, private subnets, security groups, network ACLs and VPC endpoints from the same version-controlled templates, with non-overlapping address ranges, and AWS WAF and certificates are already in place so failover does not weaken edge protection.
Cross-region data protection
Amazon S3 cross-region replication, Amazon DynamoDB replication or backups, AWS Secrets Manager replicas and regional KMS keys keep data and credentials available in the DR region.
Health-check failover
Amazon Route 53 health checks redirect the device endpoint and portal/API traffic to the DR region; devices connect through an IoT Core custom domain so they can be redirected without reconfiguration.
Pilot-light standby
Networking, replicated data stores and pre-registered device identities are in place in the DR region, and the Kinesis, Lambda and SageMaker AI layers are scaled out from infrastructure templates on failover; warm standby can be adopted if a tighter recovery time is needed.
Deliberate, runbook-driven failover
The platform team is alerted through Amazon CloudWatch alarms and Amazon SNS, and runbooks cover failover, data-store restoration, redeployment of ingestion, ML and GenAI components, and failback in a planned window with reconnection jitter so vehicles do not return in a single burst.
Tested recovery
Non-disruptive failover drills run periodically in an isolated environment to validate the procedure and recovery targets.
Target restoration of ingestion, alerting and review workflows in the DR region after a regional disruption.
Target maximum data-loss window for replicated stores such as Amazon S3 and Amazon DynamoDB; in-flight stream data is re-sent from device buffers.
RTO and RPO values are proposed starting points and should be agreed with Nuevas Technologies and validated through recovery testing.
The strongest protection where an outage matters most
Availability is delivered through five layers — redundancy across Availability Zones, decoupled stages, graceful degradation, retry and buffering, and cross-region recovery — and is matched to how critical each capability is, so cost is not spent protecting everything equally. Threshold-rule alerts never depend on SageMaker AI or Amazon Bedrock, so alerting continues if ML scoring or GenAI explanation is unavailable.
Critical
CapabilitiesTelemetry ingestion, streaming, rule-based alerting and notification.
Behavior under failureMulti-AZ managed services, device buffering, stream retention, dead-letter queues and cross-region recovery. Never depends on ML or GenAI services.
Important
CapabilitiesML anomaly scoring and event enrichment.
Behavior under failureAuto-scaled SageMaker AI endpoints across Availability Zones. If unavailable, rule-based alerts continue and scoring catches up from the stream.
Degradable
CapabilitiesGenAI explanations, draft work orders, manual retrieval, workshop lookup, dashboards and the optional portal.
Behavior under failureBedrock quotas and retries. If unavailable, alerts are sent with the structured event record, and explanations are generated when the service recovers. Staff review remains mandatory.
Numeric availability targets are to be agreed with Nuevas Technologies and validated through load testing on pilot data, dependency-failure testing — for example, disabling the Bedrock or SageMaker AI path to confirm that rule-based alerts continue — and the periodic failover drills. No availability results are claimed.
Cost that follows vehicles and events, not raw message volume
Cost visibility is addressed from the start of the engagement, following the cost optimization pillar of the AWS Well-Architected Framework. The cost baseline and tagging strategy are agreed during discovery and design, cost allocation tags are applied through infrastructure as code during build, and spend is reviewed against budgets in operation. The assessment of Nuevas Technologies’ current cost drivers is qualitative, drawn from the existing workflow rather than measured spend.
| Cost driver | As-is finding | Design response |
|---|---|---|
| Reactive maintenance | Unplanned repairs bring roadside assistance and towing, vehicle downtime, route disruption and higher repair cost. | Streaming detection and evidence-grounded explanations surface developing faults earlier so workshop visits can be planned. |
| Manual work-order effort | Staff search service manuals and prepare work orders by hand, with inconsistent quality and rework. | Draft work orders with evidence and approved manual references; staff time per work order is tracked as a KPI. |
| Spend attribution | Messaging, streaming, inference, GenAI and storage costs cannot be attributed to fleets, depots or stages, and no cost per vehicle exists. | Cost allocation tags (fleet or depot, environment, processing stage), AWS Cost Explorer reporting, cost per vehicle as the unit metric, and AWS Budgets and Cost Anomaly Detection alerts. |
| Telemetry volume growth | High-frequency readings processed at full rate and kept in one storage tier would increase messaging, streaming, storage and query costs as the fleet grows. | Report by exception, batch and compress, and use Basic Ingest; store curated data in a partitioned columnar format with S3 Lifecycle rules and Intelligent-Tiering, and set CloudWatch log retention. |
| Always-on capacity | Provisioned streams, always-on inference endpoints and Dev, Test and DR environments sit idle outside peaks or until failover. | Kinesis capacity mode chosen from pilot measurements, Lambda tuning and AWS Compute Optimizer reviews, serverless or batch SageMaker AI scoring, scaled-down Dev and Test, and a pilot-light DR region. |
| Unbounded GenAI usage | An explanation for every message, or large prompt context, would make model cost rise with fleet size. | Bedrock invoked only for qualifying events, model size chosen by event severity after evaluation, limited and cached context, and batch processing for non-urgent summaries. |
After the pilot establishes a steady baseline, Savings Plans will be evaluated for the stable portion of compute and ML usage, and spend will be reviewed against budgets and fleet maintenance KPIs on a recurring basis as the fleet grows.
What changes for dispatchers, planners and workshop teams, day to day
Earlier warning of developing faults
Rules and ML anomaly scoring surface potential faults from live telemetry, so maintenance can be planned before a breakdown occurs.
Insights people can act on
Plain-language explanations state the observed signals, timestamps, likely causes to investigate and any data limitations, instead of raw diagnostic codes.
Less time on manuals and paperwork
Draft work orders arrive with evidence, a suggested priority and approved manual references for staff to review, reducing search and preparation effort.
Better prioritization
Combined rule-based and ML-based evidence, enriched with trip, service-history and optional workshop context, helps focus attention on vehicles with the highest maintenance risk.
Trustworthy alerts
Evidence-grounded generation, explicit uncertainty language, Amazon Bedrock Guardrails and de-duplication keep anomalies distinct from confirmed failures and limit repeated alerts.
People stay accountable
Authorized staff approve every repair, scheduling and vehicle-restriction decision; nothing consequential is automated.
Secure by design and auditable
Security requirements, threat modeling and policy checks come before build, and per-device identities, least-privilege roles, KMS encryption, private networking and CloudTrail audit logging protect vehicle, location and driver data in operation.
Alerts that keep working
Connectivity loss is expected and handled, and rule-based alerts continue even if ML or GenAI services are unavailable, with the strongest protection on ingestion and alerting.
Room to scale, with costs in view
Managed, serverless and streaming services scale with fleet size and message rates across Availability Zones, Amazon Bedrock is invoked only for events that qualify, and tagging, budgets and a per-vehicle baseline keep cost proportionate as the fleet grows.
Nuevas Technologies’ expected gains
The gains below are expected outcomes of the design, not measured results. Baselines are established during discovery, numeric targets are agreed with Nuevas Technologies afterwards, and values are populated only after pilot or production measurement.
Time to detect a potential fault
Before the platform, faults were noticed only after performance deteriorated or a breakdown occurred. The platform targets a decrease in the time from the first sensor or event timestamp to the first actionable alert.
Unplanned breakdown frequency
Maintenance was reactive. Earlier, evidence-backed warnings are expected to reduce unplanned breakdowns, measured as breakdowns per vehicle or distance over a defined period.
Maintenance planning lead time
Planning lead time was short or absent. The platform targets an increase in the time between an early warning and the planned workshop action.
Work-order preparation effort
Staff searched service manuals and drafted work orders by hand. The platform targets a decrease in staff time per work order, measured before and after GenAI assistance.
False-positive rate and model quality
False positives were not systematically tracked. The platform targets a decrease over time in the share of reviewed alerts classified as benign or as sensor-quality issues, using reviewer and repair-outcome feedback to tune rules and models; model-quality thresholds are set after the pilot.
Alert pipeline health and availability
Alert-pipeline health was not tracked. Event lag, processing failures and notification delivery are monitored in Amazon CloudWatch against agreed service objectives, and the design aims for high availability through multi-AZ operation, capability tiers and cross-region disaster recovery, validated through load, dependency-failure and failover testing.
Cost visibility
Usage-based costs could not be attributed to fleets, depots or processing stages. Cost allocation tagging applied through infrastructure as code, a per-vehicle cost baseline, AWS Budgets and AWS Cost Anomaly Detection are expected to give visibility and early warning of overruns as the fleet grows.
Nuevas Technologies expects the platform to help its teams detect developing vehicle faults earlier, plan maintenance before breakdowns occur, and spend less effort preparing work orders, while keeping authorized staff in charge of every repair, scheduling and vehicle-restriction decision. Telemetry streaming, rule and ML detection, evidence-grounded GenAI explanations, security designed in from the start, connectivity and recovery planned around intermittent networks, and cost controls that follow vehicles and events together form the foundation for these outcomes.
This case study describes an illustrative solution design and expected benefits only; no measured customer results are claimed. Target directions are to be validated against baselines and measured results from CloudWatch dashboards, review feedback and maintenance records, and customer-specific details, thresholds, availability objectives and RTO/RPO values must be validated with Nuevas Technologies before external publication.
