Solution pattern · reference architecture
Condition monitoring and predictive maintenance on Databricks.
This pattern connects sensor data with asset master data, operating state, and maintenance events. Models provide traceable indicators for maintenance, but do not control a machine or replace safety-related logic.
Starting point
Sensor alarms show values, but rarely include maintenance context.
Time series sit in historians, controls, or IoT platforms while failures and work orders live in the maintenance system. Without a shared timeline and asset identifier, patterns are difficult to assess.
Business value
Condition indicators connect with maintenance decisions and feedback.
Maintenance can review trends, operating state, and event history together. Alerts have a documented origin, and business assessment feeds back into data and model quality.
What becomes measurable
- Sensor availability, time gaps, and quality of asset mapping
- Warning lead time, business-confirmed indicators, and false alerts by operating state
- Model drift, data changes, and feedback from work orders
Reference architecture
Components and their purpose
Streaming and history land in Delta Lake. Databricks creates reproducible features, MLflow versions models, and maintenance retains the decision.
- 01
Ingest signals securely
Azure IoT Hub or Azure Event Hubs receives approved telemetry through a secured OT boundary. Device identity and timestamps are validated.
- 02
Retain raw time series
Azure Data Lake Storage Gen2 and Delta Lake store raw signals, quality flags, and ingestion context in the Bronze layer.
- 03
Build context and features
Azure Databricks aligns timelines, joins asset master data and operating state, and creates versioned features in Silver and Gold.
- 04
Develop traceable models
MLflow records the dataset, parameters, metrics, artefacts, and approval status. A simple rule model remains a possible baseline.
- 05
Provide indicators
Batch or stream scoring creates prioritised condition indicators for Power BI or the maintenance system, not for direct machine control.
- 06
Monitor feedback and drift
Confirmed findings, false alerts, and work orders return through a controlled path. Azure Monitor and Databricks observe pipeline, data, and model behaviour.
Technology
Concrete services for implementation
The selection is adapted to existing contracts, regions, security requirements, and the actual scope.
- Azure IoT Hub
- Azure Event Hubs
- Azure Data Lake Storage Gen2
- Azure Databricks
- Delta Lake
- MLflow
- Unity Catalog
- Azure Monitor
- Power BI
First project scope
A pilot needs clear boundaries
The first deployment tests data, integration, and the working process in a limited area. It is not a premature enterprise rollout.
Deliberately included
A clearly bounded machine family and a well-understood condition, available sensor history, asset master data, maintenance events, and an indicator dashboard with documented feedback.
Deliberately excluded
No plant-wide rollout, autonomous shutdown or control, changes to safety PLCs, guarantee of failure predictions, or model for unknown failure modes without reliable data.
Prerequisites and constraints
Technology does not replace data accountability
Data access, responsibilities, licences, and operations must be clear before implementation. Open points are treated as project risks.
- 01Sensor quality, time synchronisation, operating states, and stable asset identifiers determine whether a model can be evaluated meaningfully.
- 02OT access, network segmentation, data buffering, and responsibility boundaries must be agreed with operations and information security.
- 03Reliable labels are often missing for rare failures. Business rules or condition monitoring alone can then be more suitable than supervised prediction.
- 04Maintenance, production, automation, OT security, data engineering, and model ownership must decide together how an alert is handled.
Germany and the EU
Compliance follows the specific purpose
Machine data can become personal data through shifts, workstations, or operator actions. GDPR, purpose limitation, and clear deletion and access rules then apply. The system must not silently become a performance or behaviour monitoring tool, and early works council involvement under the Works Constitution Act is required where that capability exists. The intended purpose and any connection to employment, safety, or critical products must be assessed under the EU AI Act. Data and model operations should be planned in suitable EU regions and verified contractually.
Free initial assessment
Which asset condition is understood by specialists but not yet connected in data?
The discovery call frames signals, events, OT boundaries, response, and a testable pilot scope.
The initial consultation and joint use-case discovery are free and non-binding.
Related use cases
Condition monitoring for one critical asset
Sensor values, faults, and maintenance orders are separate. Rare or poorly labelled failures make a dependable condition view difficult.
Complaint and quality root-cause analytics
Complaints, defect codes, batches, and process values live in separate systems. Recurring patterns are therefore identified late.
Spare-parts and inventory optimisation
Critical parts are missing while others sit in stock for years. Consumption, asset criticality, lead time, and equivalent parts are rarely assessed together.