Reducing unplanned downtime in automotive paint shops requires unifying siloed operational data into a contextualized fabric that enables AI-driven root cause analysis and anomaly detection. Today, when a paint shop line goes down, the industrial engineer must manually correlate data across Supervisory Control and Data Acquisition (SCADA) systems, Manufacturing Execution Systems (MES) platforms, downtime logs, and energy management dashboards, then conduct root cause analysis through experience and intuition; a process that routinely takes hours and often yields incomplete answers. An Industrial Data Fabric (IDF) on AWS addresses this challenge by connecting disparate data sources into a unified, contextualized knowledge graph that preserves the relationships between machines, processes, materials, and operators.

A unified data layer, however, is only the foundation. Human intelligence and intervention are still required to contextualize and act on the data, identify correlations across hundreds of parameters, and determine whether an emerging pattern signals an imminent failure. What if that analytical burden could be offloaded to AI agents engineered with deep understanding of the plant’s operational context?

In this blog, we showcase how Mahindra AI collaborated with AWS to architect and deploy an enterprise-grade Industrial Data Fabric (IDF) in Mahindra & Mahindra’s Auto business’s paint shop. By pairing Mahindra AI’s engineering capabilities with AWS-native services, the team established a scalable, intelligent foundation designed to optimize throughput and operational efficiency across the core 4M pillars: Man, Machine, Method, and Material. The solution integrates IIOT data from shop floor assets and operational systems into a unified contextual graph, powering autonomous anomaly detection, predictive analytics, and agentic root cause analysis (RCA) capabilities directly on the shop floor.

Like many high-volume manufacturing environments, automotive paint shops generate massive streams of operational data across disparate platforms. To transform this complexity into a competitive advantage, Mahindra AI spearheaded an initiative to replace reactive troubleshooting with proactive, agentic operational intelligence. By deploying specialized machine learning workflows alongside contextual RCA agents, shop-floor engineers can now query complex operational events in natural language, dramatically accelerating root-cause identification and decision velocity.

We walk through the end-to-end solution approach, covering data integration, contextualization, knowledge graph creation, machine learning workflows, and AI-driven investigation capabilities. The blog highlights how these building blocks come together to create a reusable framework for improving manufacturing performance and accelerating data-driven decision-making on the shop floor.

The solution covers plant-floor data extraction through contextualization, knowledge graph construction, ML model training, and agentic AI deployment, including the connectivity design, data pipeline orchestration, and the agent configurations.

Solution overview

Consider a typical automotive paint shop — pre-treatment tanks, electro-deposition coating, primer application, topcoat booths, and baking ovens – all orchestrated by SCADA with MES tracking production flow and quality gates. Hundreds of sensor tags stream temperature, pressure, flow rate, and humidity readings, but the data sits in disconnected silos. For example, the SCADA system stores process data in one relational database, the MES platform uses a separate backend, asset downtime records live in Excel sheets, and energy consumption data resides in yet another database hosted on a different cloud. The Industrial Data Fabric joins these silos into a single, contextualized data layer that powers both ML-based anomaly detection and GenAI-driven investigation.

Figure 1: Solution architecture

How it works

1. Data extraction from plant floor — Incremental data is pulled from the SCADA database (MySQL), MES staging database (Oracle), and supplementary sources (Excel-based downtime logs, P&ID documents, energy management system). Data passes through the customer’s existing security appliances and WAN connectivity from the plant to their corporate data center.
2. Secure cloud ingestion — From the data center, data is routed to a Mahindra AWS account that is dedicated to managing the Industrial Data Fabric (IDF) on AWS via Virtual Private Network(VPN) connectivity and AWS Transit Gateway. Change data lands in Amazon S3 in CSV/Parquet format for downstream processing.
3. Data contextualization — An AWS Fargate for Amazon ECS-based contextualization engine adds operational metadata to raw data — mapping sensor tags to their physical assets, associating readings with process stages, and enriching records with asset hierarchy and functional location information. This transforms raw time series data into business-meaningful observations. For example, “Tank 3 pH drifting outside process window” rather than “tag_PT_003_pH = 4.2”.
4. Knowledge graph construction — Contextualized data feeds into Amazon Neptune, where a Method & Machine Knowledge Graph captures the relationships between assets, processes, failure modes, and operating parameters. The graph models the paint shop’s topology — which robot serves which booth, which pumps feed which tanks, which parameters influence which quality outcomes — enabling the agent to trace a problem across multiple connected steps in the process chain during investigation.
5. Unstructured data vectorization — P&ID diagrams, Why-Why analysis documents, and historical RCA reports are converted to vector embeddings using Amazon Bedrock Knowledge Bases and stored in Amazon OpenSearch. This gives the AI agents access to tribal knowledge and engineering documentation during investigation.
6. ML model training and deployment — Amazon SageMaker trains anomaly detection models on historical data patterns — learning the “golden profiles” for normal operation across pre-treatment and electro-deposition tanks. Trained models are deployed for batch inference, triggered by Amazon EventBridge on a scheduled cadence. Inference results (anomaly scores, contributing parameters) persist in Amazon DynamoDB for real-time access by the agentic layer.
7. Agentic AI for investigation — Two specialized agents run on Amazon Bedrock AgentCore Runtime: An Operations Advisor Agent that provides an overview of plant machinery health and recommends maintenance actions before failures occur, and a Process Investigation Agent that enables natural language root cause analysis by correlating time-series data, knowledge graph relationships, and historical RCA patterns.
8. Agent-to-data interfaces — Agents use either MCP protocols or AWS Lambda functions to interface with data sources. Amazon Athena retrieves time-series data from Amazon S3 for trend analysis. Lambda functions orchestrate agent calls and expose responses via Amazon API Gateway for frontend integration.
9. Visualization and dashboards — Amazon Quick powers KPI views across dashboards, including drilldowns for downtime analysis, energy consumption, and equipment health. Dashboards are shared with paint shop users — from operators to plant managers — providing real-time visibility into asset performance.
10. Frontend for operators — An AWS Amplify-hosted frontend provides the primary interface for paint shop users to interact with the AI agents, view dashboards, and trigger investigations.

Key differentiator: The knowledge graph encodes the plant’s operational logic, asset relationships, and process constraints. When an agent investigates a failure, it can traverse the graph to identify upstream causes that a traditional time-series analysis would miss. For example, a topcoat defect might trace back through the graph to a pre-treatment tank chemical imbalance three stages earlier.

From siloed data to contextualized fabric

The hardest part of any manufacturing AI initiative is data preparation. Plant floor data exists in formats optimized for control systems, not for analytics or AI. A SCADA tag named PT_ED_T4_TEMP_01 means nothing to an ML model or an LLM without the context that it represents “Electro-Deposition Tank 4, Temperature Sensor 1, measuring bath temperature in degrees Celsius, with an acceptable operating range of 28–32°C.”

The contextualization layer on AWS Fargate for Amazon ECS performs this translation at scale. It consumes raw data from Amazon S3, enriches it using asset hierarchy definitions and functional location mappings, and produces contextualized records that carry their own meaning. The enrichment logic handles:

• Tag-to-asset mapping — Associating raw sensor tag IDs with their physical equipment, location in the plant topology, and process stage
• Unit standardization — Converting heterogeneous units across data sources into a consistent engineering unit framework
• Temporal alignment — Synchronizing readings across systems that operate on different sampling frequencies (SCADA at sub-second, MES at batch boundaries, energy meters at 15-minute intervals)
• Relationship encoding — Tagging each observation with its upstream and downstream dependencies in the process flow

This contextualized data then feeds two parallel paths: the knowledge graph in Amazon Neptune and the time series data in Amazon S3.

Building the knowledge graph

Amazon Neptune hosts the Method & Machine Knowledge Graph — a property graph that models the paint shop as an interconnected system. The graph schema captures:

• Asset nodes — Every physical equipment piece (robots, pumps, tanks, ovens, conveyors) with asset properties: manufacturer, commissioning date, maintenance history, criticality rating
• Process nodes — Each process stage (pre-treatment, ED coating, primer, topcoat, baking) with process parameters: standard operating conditions, quality gates, typical cycle times
• Failure mode nodes — Known failure patterns extracted from historical downtime data and Why-Why analysis documents, linked to their contributing factors and affected assets
• Parameter nodes — Operating parameters with their acceptable ranges, alarm thresholds, and correlation coefficients to downstream quality outcomes
• Relationships — “feeds_into,” “controls,” “triggers,” “causes,” “mitigated_by,” “located_at” — encoding the causal and topological structure of the plant

As new data flows through the contextualization layer, the graph updates — new failure events are linked to their contributing parameters, maintenance actions are recorded against assets, and operational patterns are reinforced or deprecated based on observed outcomes.

When the Process Investigation Agent receives a query, it builds the causal chain with explainable logic. A question about a topcoat defect might traverse: Defect → Topcoat Booth → Paint Supply System → Viscosity Sensor → Temperature Controller → Chiller Unit — to ultimately surface that the chiller had been operating 2°C above setpoint for the preceding 4 hours.

Anomaly detection with Amazon SageMaker

The ML layer operates on the principle of “golden profiles” — statistical representations of what normal operation looks like for each monitored subsystem. For the pre-treatment and electro-deposition sections (covering multiple tanks across both process stages), the solution trains multivariate anomaly detection models that learn the co-variance structure of operating parameters under healthy conditions.

The modeling approach uses:

• Training data — Historical periods identified as “healthy operation” (no recorded downtime events, quality metrics within specification) to establish baselines
• Feature engineering — Rolling statistics (mean, variance, rate of change) computed over multiple time windows to capture both sudden deviations and gradual drift
• Model architecture — Ensemble of isolation forests and autoencoders that capture different failure signatures. For example, isolation forests excel at point anomalies while autoencoders detect subtle multivariate drift

Models are retrained monthly as new operational data accumulates, ensuring baselines evolve with process changes (seasonal adjustments, new paint formulations, equipment replacements). Batch inference runs on an Amazon EventBridge-triggered schedule, scoring the latest operational data and persisting results to Amazon DynamoDB with anomaly scores, contributing parameter rankings, and confidence intervals.

The anomaly detection layer issues early warnings. It does not act on them. When an anomaly score exceeds the configured threshold, the Operations Advisor Agent picks it up, cross-references the contributing parameters against the knowledge graph, and generates an actionable alert: “Tank 7 conductivity trending 15% above golden profile. Knowledge graph indicates this parameter correlates with filter bypass valve position — recommend inspection.”

Agentic AI for root cause analysis

What brings the architecture together is the pair of AI agents running on Amazon Bedrock AgentCore. The agents query the IDF directly, so engineers can investigate issues through them rather than pulling data by hand.

Operations Advisor Agent

The Operations Advisor provides a shift-level briefing on plant health. It queries Amazon DynamoDB for the latest anomaly scores, traverses the Amazon Neptune knowledge graph for asset criticality and maintenance due dates, and generates a prioritized list of attention items. Plant engineers no longer need to manually review 15 dashboards at the start of their shift — the agent synthesizes the information into a single conversational briefing.

Process Investigation Agent

The Process Investigation Agent handles ad-hoc root cause analysis. When an operator encounters an issue such as a paint defect, an unexpected stoppage, an out-of-spec reading — they query the agent in natural language. The agent’s investigation workflow:

1. Parse intent — Understands what the operator is asking about (which asset, which time window, what symptom)
2. Retrieve time-series — Uses Amazon Athena (via AWS Lambda) to pull relevant sensor data from Amazon S3 for the specified time window
3. Traverse knowledge graph — Queries Amazon Neptune to identify related assets, upstream/downstream dependencies, and known failure modes matching the symptom
4. Retrieve documentation — Searches the Amazon OpenSearch vector store for relevant P&ID sections, historical RCA reports, and Why-Why analysis documents
5. Synthesize answer — Combines quantitative data, relational context, and historical precedent into a coherent root cause hypothesis with supporting evidence

This workflow replaces the manual process where an engineer would spend 2–4 hours pulling data from different systems, building Excel charts, and correlating events across timelines. The agent completes the same investigation in minutes, with full traceability to source data.

Results and impact

The IDF implementation at this Mahindra paint shop delivered measurable outcomes:

• Faster root cause analysis through AI-assisted investigations, reducing MTTR (Mean Time to Repair) by 20%
• Greater operator autonomy with self-service, natural language access to insights.
• Earlier issue detection from ML models running on live process data.
• Scalable architecture that establishes a reusable foundation for industrial AI initiatives, reducing time for horizontal deployment across other shop floors by 30%.

Together, Mahindra AI and AWS created a contextualized industrial data foundation that improves throughput, speeds up decision-making, and supports continuous operational improvement.

Conclusion

Through a collaboration between Mahindra AI and AWS, an Industrial Data Fabric was successfully implemented to enable smarter, data-driven paint shop operations. By combining contextualized industrial data, knowledge graphs, machine learning, and AI-powered investigations, the solution established a scalable foundation for improving operational efficiency, speeding up decision-making, and driving continuous improvement across manufacturing operations.

What’s next for this pattern:

• Scale across manufacturing operations using a repeatable Industrial Data Fabric and AI architecture.
• Advance from detection to recommendations with increasingly intelligent operational decision support.
• Expand AI use cases across quality, energy, maintenance, and production operations.
• Extend the pattern to additional processes across the manufacturing value chain.

This approach provides a scalable foundation for accelerating AI-driven transformation across manufacturing operations.

Have questions about implementing an Industrial Data Fabric for your manufacturing operations? Want to discuss how this pattern could apply to your plant processes? Reach out to your AWS Solutions Architect to explore an opportunity to get started on a proof of concept.

Mahindra & Mahindra (M&M) is an Indian multinational automobile manufacturing company headquartered in Mumbai. It is the flagship company of the Mahindra Group — a conglomerate with operations in over 100 countries and 324,000+ employees. India’s largest SUV manufacturer by revenue, and the second-largest domestic player in the passenger vehicle segment by revenue market share.

Mahindra AI operates as the group’s captive centre of excellence, engineered to drive AI across group businesses. By integrating domain expertise with advanced AI and cloud-native architectures, the team develops scalable AI solutions that power Mahindra’s smart factories and beyond.