Organizing Brownfield Data Across Multiple Plants.
Predictive Maintenance with Knowledge Graphs: From Sensor Data to Proactive Scheduling
Predictive Maintenance with Knowledge Graphs: From Sensor Data to Proactive Scheduling
7:41
Sensor data tells you something is wrong. A knowledge graph tells you what to do about it — which assets are affected, which engineers are available, which parts are in stock, and when the maintenance window fits the operational schedule.
Most organizations operating distributed physical assets have the data. IoT platforms, sensor readings, and anomaly detection models that flag equipment at risk. The alerts fire. And yet the question that follows every alert — what do we do about it, and when? — still takes hours or days to answer.
The bottleneck is operational context. Knowing that Gearbox G-07 is showing vibration anomalies is only half the picture. The decisions that matter require knowing which engineers are certified and available, whether the required part is in stock, and when the next maintenance window aligns with the operational schedule. That information exists but it lives across separate systems that do not talk to each other.
Connected operational intelligence changes this. By modelling the relationships between assets, workforce, inventory, and schedules in a shared semantic layer, the path from anomaly to scheduled intervention becomes a traversal rather than a manual investigation. Maintenance planning shifts from coordination overhead to operational decision-making.
|
Predictive maintenance that only identifies failure risk is half the answer. The full answer requires connecting that risk signal to workforce, inventory, and scheduling data and producing a decision, not just an alert. |
The gap between detection and decision
An anomaly detection model that flags a gearbox at risk of failure has completed one step in the maintenance workflow. The steps that follow are where operational efficiency is won or lost:
- Which engineers hold a current certification for this asset class, and which are within a practical travel radius of the site?
- Is the required replacement part available at the site depot, or does it need to be ordered?
- Does the intervention slot before the next high-demand operational window, or does delay carry revenue risk?
- Are there other assets at the same site showing early warning indicators that could be grouped into the same maintenance visit?
When each of these questions requires a separate lookup across disconnected systems, the planning cycle stretches. In energy generation, that delay has a direct financial consequence: Availability Loss Revenue (ALR) — the cost of an asset being offline during a period when it could be generating.
|
Maintenance timing as a business decision ALR reframes predictive maintenance from a cost-reduction exercise into a revenue protection exercise. The question is not just “when does this asset need maintenance?” but “when is the optimal window that balances failure risk against generation opportunity?” An intervention scheduled before a high-wind period preserves the full generation window. An intervention delayed by poor scheduling coordination does not. Connected operational intelligence makes that optimization possible at scale, accounting for asset risk, weather forecasts, workforce availability, and operational constraints simultaneously. |
From data silos to connected operational reasoning
The information needed to answer every maintenance planning question already exists across the organization — in asset management systems, workforce platforms, inventory databases, and operational scheduling tools. What those systems lack is a shared understanding of how the entities in each relate to the others.
A semantic layer built on a knowledge graph provides that shared model. Assets, components, engineers, certifications, parts, and schedules are defined as connected entities. When a sensor reading indicates a failure risk, the system traverses those connections in a single operation: asset → failure mode → maintenance procedure → certified engineer → availability window → parts inventory → operational schedule. The answer is a scheduling recommendation, not a prompt to start five separate lookups.
This is the shift from reactive maintenance to proactive operations: the intelligence to act is available at the moment it is needed, grounded in the current state of assets, people, and operational constraints.
|
“Which specific gearboxes at our wind farms show vibration anomalies correlated with high-wind forecasts? Let’s proactively schedule maintenance to ensure we capture 100% of the next peak generation window.” Without connected operational intelligence: five separate system lookups, manual reconciliation, hours to a scheduling decision. With a semantic knowledge graph: a single traversal from anomaly signal to scheduling recommendation, grounded in live workforce, parts, and operational data. |
What the semantic model connects
The maintenance knowledge graph models the entities and relationships that matter operationally, not just asset data, but the full operational context surrounding each asset.
|
Entity |
Connected to |
Enabling this operational question |
|
Asset / Component |
Sensor readings, failure modes, maintenance history |
Which assets are at risk, and what is the likely failure type? |
|
Failure Mode |
Asset class, maintenance procedure, parts required |
What intervention does this failure type require, and what parts are needed? |
|
Engineer |
Certifications, location, current assignment |
Who is qualified and available to respond? |
|
Inventory / Parts |
Depot location, lead time, asset compatibility |
Is the required part in stock at the nearest depot? |
|
Operational Schedule |
Site, asset, generation windows, constraints |
When is the optimal maintenance window that protects revenue? |
|
Work Order history |
Asset, engineer, parts used, root cause |
What patterns in failure history can inform proactive scheduling? |
|
The network effect: each new domain added to the semantic model increases the value of everything already in it. Adding weather data to an asset-and-engineer model enables failure rate correlation with operating conditions. Adding inventory enables scheduling decisions that account for parts availability. Connected operational intelligence compounds. |
Connected operational intelligence in practice
|
Scenario 1: Vibration anomaly to proactive scheduling (Wind energy) A sensor flags Gearbox G-07 at Site B with vibration anomalies. The predictive model indicates a high probability of bearing failure within 21 days. The knowledge graph traversal returns: two certified engineers within range, one available in the 14-day window; the required bearing in stock at the Site B depot; a planned maintenance window on Day 11; and two other gearboxes at the same site showing early indicators. The scheduling recommendation: a consolidated visit in the Day 11 window, covering all three gearboxes, with confirmed engineer and parts. The peak generation window beginning Day 14 is protected. Outcome: proactive intervention, consolidated visit, full revenue window protected. |
|
Scenario 2: Resource optimisation across distributed sites (Energy) Simultaneous maintenance alerts arrive across three geographically dispersed sites. The operational question is not just whether each site has a qualified engineer, it is how to allocate a constrained pool of specialist engineers to minimize total ALR exposure across all three. The knowledge graph maps engineer certifications, current assignments, travel times, asset criticality, and generation forecasts across all sites in a single query, producing a prioritized allocation that accounts for all constraints. The multi-hour coordination call that would previously have preceded this decision resolves in minutes. Outcome: optimized multi-site allocation, ALR exposure minimized, no manual coordination overhead. |
|
Scenario 3: Agentic maintenance coordination (Autonomous operations) As trust in the semantic model builds, organizations move from scheduling support to agent-driven coordination. An AI agent monitors the asset network continuously, identifies maintenance opportunities based on failure risk and operational windows, checks engineer and parts availability through the knowledge graph, and generates draft work orders for planner approval. The maintenance planner’s role shifts from information gathering to decision review. The time between anomaly detection and scheduled intervention compresses from days to hours. Outcome: faster intervention cycles, planner focus on exceptions, autonomous coordination at network scale. |
How it works on the Databricks Lakehouse
Kobai’s connected operational intelligence architecture is built directly on the Databricks Lakehouse. Operational data from IoT platforms, asset management, workforce, inventory, and scheduling systems is unified into a semantic model on governed Delta tables. Graph traversals execute on Databricks compute under Unity Catalog governance. The semantic layer is authored and maintained by domain experts — maintenance engineers and operations planners — using no-code visual tooling.
AI-assisted planning through Episteme answers operational questions in plain language with full traceability. As the model matures, agent-driven workflows can automate routine scheduling decisions, with maintenance planners reviewing exceptions rather than assembling context.
|
Layer |
What it provides |
|
Databricks Lakehouse |
Governed storage and compute. Unity Catalog access controls apply to all operational data and semantic outputs. |
|
Semantic model (Studio) |
Domain experts define the maintenance ontology — assets, engineers, certifications, parts, schedules. No-code, maintained by the people who understand the operational domain. |
|
Graph layer (Saturn) |
Semantic graph index built over Delta tables. Graph traversals execute as SQL on Databricks compute. No data duplication. |
|
Intelligence layer |
Episteme: AI-assisted maintenance Q&A with answer lineage. Tower: maintenance planner dashboards. Genie: conversational operational intelligence. Agents: automated scheduling workflows. |
From reactive maintenance to proactive operations
The shift from reactive maintenance to proactive operations is fundamentally about decision speed and decision quality. When the operational context needed to act on a sensor signal is available in seconds rather than hours, maintenance becomes a scheduling optimization problem rather than a coordination overhead.
Connected operational intelligence on the Databricks Lakehouse — built on Kobai’s semantic layer, Episteme AI, and governed graph traversal — provides that capability for organizations operating distributed physical assets. Assets at risk are identified earlier. Interventions are scheduled at the right time, with the right people and parts, to protect operational windows and reduce revenue loss from unplanned downtime. As the model matures, autonomous coordination handles routine decisions, freeing maintenance planners to focus on the interventions that require judgement.
If you operate distributed physical assets and want to explore how connected operational intelligence can accelerate the shift to proactive maintenance, speak with us at kobai.io or contact@kobai.io.
COMMENTS
