Predictive maintenance AI learns the normal behaviour of an asset from sensor, SCADA and maintenance data, then flags deviations early and, where the data supports it, estimates remaining useful life. Alerts become work orders in SAP PM, IBM Maximo or Odoo. It works when you have enough history, accurate failure records and a team that will act on alerts; without those it produces noise.
Swedish Technology starts every predictive maintenance project with a data-readiness assessment, because the honest answer for some assets is that condition monitoring rules will outperform a model until the failure history improves.
What problem does this solve?
Maintenance organisations sit between two expensive extremes. Run-to-failure means unplanned downtime, emergency spares at emergency prices and safety exposure. Fixed-interval preventive maintenance means opening healthy machines on a calendar, consuming labour and sometimes introducing faults that were not there before. Most plants know that a portion of their preventive work is unnecessary and that a portion of their failures were preceded by weeks of visible warning signs — but they cannot say which is which, because the evidence is spread across a historian, a SCADA system, a CMMS and the knowledge of two long-serving technicians.
The data problem is usually worse than the modelling problem. Sensor history exists, but with gaps, unit changes, tags renamed after a control system upgrade and no record of when the machine was idle versus loaded. Failure history exists in the CMMS, but as free-text notes: 'pump noisy, repaired', with no failure code, no failure date distinct from the repair date, and no distinction between a bearing failure and a seal leak. A model trained on this cannot learn what a failure looks like, because nobody wrote down when the failures happened.
The third problem is what happens after the first alert. Predictive systems fail in production far more often through alarm fatigue than through poor mathematics. If a model raises twenty alerts a week and eighteen are noise, the reliability engineer stops reading them within a month, and the two real warnings are lost with the rest. Without an owner for triage, a severity policy and a route from alert to work order, a technically correct model produces no maintenance outcome at all.
How the solution works
Predictive maintenance AI is built in two halves. The first half learns what normal looks like for each asset from its own history — vibration, temperature, motor current, pressure, flow, runtime and load, aligned in time and cleaned of the periods when the machine was off or in an abnormal operating mode. Deviations from that learned baseline produce an anomaly score with the contributing signals identified, so an engineer sees not only that something changed but which measurements changed. This half works with relatively little failure history, because it learns normality rather than failure.
The second half needs labelled failures: a classifier that maps a developing pattern to a specific failure mode, and a remaining-useful-life estimate that gives a time window rather than a single date. RUL is only credible where the degradation is gradual, measurable and has been observed several times on comparable assets; where it is not, we say so and deliver anomaly detection with a condition-based rule set instead. Swedish Technology develops these systems as custom engineering work, including the integration that turns a reviewed alert into a work order in SAP PM, IBM Maximo or Odoo, and the feedback loop that returns the closed work order and its failure code as a training label.
- 1Input Asset list with criticality, existing sensors and tags, historian or SCADA access, and the maintenance history from the CMMS including failure codes, work orders and downtime records.
- 2Capture Time-series data is collected continuously from the historian, an IoT gateway or, for assets with no instrumentation, from newly installed vibration and temperature sensors on the machines that justify the cost.
- 3Preparation Signals are aligned to a common time base, resampled, gap-flagged and tagged with operating context (running, idle, start-up, load band). Operating context is what separates a real deviation from a machine simply doing a different job.
- 4Processing A baseline model of normal behaviour is fitted per asset or per asset family; anomaly scores are produced continuously; where failure history allows, a failure-mode classifier and an RUL estimate with a confidence band are added.
- 5Triage Alerts are scored by severity and confidence, grouped so one developing fault does not generate fifty notifications, and reviewed by a reliability engineer who can accept, defer or dismiss with a reason.
- 6Integration & action An accepted alert creates a notification or work order in SAP PM, IBM Maximo or Odoo with the asset, symptom, evidence charts and recommended inspection, and follows the plant's normal planning and scheduling process.
- 7Reporting & learning Closed work orders return the actual finding and failure code; precision and recall of the alerts are tracked over time; models are retrained and thresholds adjusted with real outcomes rather than assumptions.
Reference architecture
The design goal is that the plant control layer is never dependent on the analytics layer. Data flows out of operations into analytics, and only human-reviewed recommendations flow back into the maintenance process.
| Layer | What it contains |
|---|---|
| Edge & data acquisition | Existing historian and SCADA tags read through OPC UA or vendor connectors; new sensors (vibration, temperature, current) added only where the asset criticality justifies it, with an IoT gateway that buffers locally when the network drops. |
| Data platform | Time-series store plus an asset model that links tags to equipment in the CMMS hierarchy, with data-quality monitoring for missing values, frozen sensors, unit changes and tag renames. |
| Analytics & models | Per-asset baselines and anomaly detection, failure-mode classification where labels exist, RUL estimation where degradation is observable, and a feature store so features are computed identically in training and production. |
| Alerting & triage | Severity policy, suppression and grouping rules, an engineer review queue with evidence charts, and an audit trail of every decision — accepted, deferred or dismissed with a reason. |
| Integration & MLOps | A service layer creating notifications and work orders in SAP PM, IBM Maximo or Odoo and reading their closure data back; model versioning, drift monitoring and a scheduled re-evaluation cycle. |
Deployment options: The full stack runs on-premise for plants that will not export operational data, in a UAE-region private cloud where the customer prefers managed infrastructure, or in a hybrid form with edge collection on site and analytics in a controlled environment. No design requires a vendor cloud outside the customer's jurisdiction.
Key capabilities
Normal-behaviour baselines per asset
Engineers see deviations relative to how that specific machine actually behaves, instead of generic thresholds copied from a manual.
custom developmentMultivariate anomaly detection
Early warnings that no single-sensor threshold would catch, with the contributing signals ranked so the engineer knows where to look.
custom developmentFailure-mode classification
Where failure history is good, the alert names a likely fault type — bearing, misalignment, cavitation, fouling — so the right craft and spares are planned.
custom developmentRemaining useful life estimates
A time window with a confidence band for gradual, well-observed degradation, allowing work to be scheduled into a planned outage.
custom developmentAlert triage and suppression
One developing fault produces one tracked case, not a stream of notifications, which is what keeps engineers reading the alerts after month three.
availableWork order creation in the CMMS
Reviewed alerts enter the existing planning process automatically, with evidence attached, rather than being emailed and forgotten.
custom developmentData-quality monitoring
Frozen sensors, dead tags and unit changes are flagged as data faults instead of being silently learned as normal behaviour.
availableReliability reporting
Alert precision, warning lead time and avoided downtime reported per asset class so the programme can be defended with numbers.
availableIntegrations
Predictive maintenance only pays back through the maintenance system. All integrations below are engineered against the customer's own instances and licences as custom development; Swedish Technology is not a certified reseller of these platforms.
| System | Integration point & data exchanged | Direction |
|---|---|---|
| SAP PM / SAP S/4HANA Asset Management | Read functional locations, equipment and maintenance history; create maintenance notifications and work orders from reviewed alerts; read closure data and failure codes back as labels. Interfaced through OData or the customer's integration platform. → RFID Integration with SAP, Oracle, Odoo & IBM Maximo | bi-directional |
| IBM Maximo | Asset and location hierarchy sync, condition monitoring points, work order creation and status updates through Maximo REST/OSLC APIs. → ArcGIS – IBM Maximo Integration | bi-directional |
| Odoo Maintenance | Equipment records, maintenance requests and preventive schedules linked to model alerts through XML-RPC/JSON-RPC for plants running Odoo as their ERP. | bi-directional |
| Historian / SCADA (OPC UA) | Continuous tag reads for process and condition signals, with buffering at the edge and no write-back to the control system. | inbound |
| GIS asset register | For distributed assets — pumping stations, substations, network equipment — alerts are shown against the spatial asset record and routed by geography. → ArcGIS – IBM Maximo Integration | bi-directional |
| Business intelligence | Downtime, alert precision and maintenance cost KPIs published to the organisation's reporting layer for management review. → Business Intelligence | outbound |
Industry use cases
Water and wastewater utilities
Pump sets monitored for bearing wear, cavitation and impeller fouling; alerts scheduled into planned outages instead of emergency call-outs at night.
Power and electrical distribution
Transformer and switchgear thermal and load patterns tracked for early degradation, with findings recorded against the asset register.
Oil & gas processing
Rotating equipment and heat exchanger fouling monitored, with cleaning intervals driven by condition rather than by calendar.
Manufacturing lines
Motors, gearboxes, compressors and conveyors watched for developing faults, correlated with quality defects from line inspection systems.
Facility management portfolios
Chillers, AHUs and lifts across a property portfolio monitored centrally, with work orders raised in the FM system and technicians dispatched by severity.
UAE & GCC considerations
Operational technology data in the UAE and GCC is frequently classified under national information-security policies, and utilities, energy operators and government entities generally require that it stays inside the country and often inside the plant network. Every component of our predictive maintenance designs can run on-premise or in a UAE-region private cloud under the customer's control, including model training; air-gapped installations receive model updates as signed offline packages. Interfaces, dashboards and alert texts are delivered in Arabic and English, and failure codes are aligned with the terminology already used in the customer's SAP, Maximo or Odoo configuration rather than a new vocabulary. Procurement here typically expects a scoped assessment or pilot on a defined asset class with measurable acceptance criteria before a portfolio-wide programme, plus documented hand-over and locally available support — which is how we structure these engagements.
Implementation approach
- 1Data readiness assessment (2–4 weeks) Inventory of assets, sensors, tags, historian coverage and CMMS failure history; a written verdict on which assets are candidates now, which need instrumentation, and which are better served by simple condition rules.
- 2Asset and failure-mode selection Choose a small set of critical assets with real failure history and a clear cost of downtime. Predictive programmes that start with 'all assets' rarely produce a result in the first year.
- 3Data pipeline build Historian/SCADA connectors, edge gateway where needed, time alignment, operating-context tagging and data-quality monitoring.
- 4Baseline and model development Fit normal-behaviour models, evaluate against known historical failures, and calibrate thresholds against how many alerts the team can actually review each week.
- 5Alert triage design Agree severity levels, ownership, response expectations, suppression rules and the exact route from alert to work order — with the maintenance planner in the room.
- 6CMMS integration Build and test the SAP PM, Maximo or Odoo interface including work order creation, attachment of evidence and read-back of closure data.
- 7Shadow operation (6–12 weeks) Alerts are produced and reviewed but do not yet drive work orders automatically; precision and lead time are measured against reality and thresholds are tuned with evidence.
- 8Go-live, review cycle and hand-over Production operation with a monthly reliability review, retraining schedule, documentation, and hand-over of models, pipelines and source code to the customer's team.
Security & deployment
The analytics platform reads from the operational network and never writes to it: no set-points, no control actions, no automatic shutdowns. Data flows through a one-way or strictly controlled path into the analytics zone, following the plant's network segmentation, and the CMMS integration runs through a service layer holding its own service account rather than embedding ERP credentials in analytic code. Every alert, review decision and generated work order is logged with user, timestamp and model version, which is what makes the programme defensible in an audit or an incident investigation. For classified environments the entire stack, including training, runs on-premise or air-gapped.
Limitations & prerequisites
- No usable failure history means no reliable failure prediction. Anomaly detection still works, but a model cannot learn the signature of a failure mode that was never recorded as such.
- Remaining useful life is only meaningful for gradual, observable degradation seen several times on comparable assets. For sudden failures — electrical faults, foreign object damage, control faults — an RUL number would be fiction, and we will not supply one.
- Sensors that do not measure the failure mechanism cannot predict it. A temperature probe on a housing will not see a developing bearing fault early; instrumentation gaps are a capital decision, not a modelling one.
- Operating-context changes — new product, different load profile, refurbishment, control system upgrade — invalidate baselines and require retraining. Unmanaged, this appears as a sudden burst of false alarms.
- Alarm fatigue is the main cause of programme failure. Without a named owner for triage and an agreed weekly alert budget, the system will be ignored regardless of its accuracy.
- Benefits appear as avoided downtime, which is inherently harder to prove than a direct cost saving. Baseline downtime and cost figures must be captured before go-live or the business case cannot be closed afterwards.
- Integration depends on API access to SAP, Maximo or Odoo being granted, and on the asset hierarchy being consistent between the historian tags and the maintenance system — a mismatch here delays projects more often than the modelling does.
Reactive vs preventive vs condition-based vs predictive AI
Predictive AI is one option on a ladder, not the top of it in every case. Choose per asset class, based on criticality, failure mode and available data.
| Criterion | Reactive (run to failure) | Preventive (calendar) | Condition-based rules | Predictive AI |
|---|---|---|---|---|
| Trigger for work | Failure occurs | Time or runtime interval | Threshold on a measured value | Learned deviation and estimated risk |
| Data needed | None | Runtime hours | Sensors and agreed limits | History, operating context and failure records |
| Typical warning time | None | Not applicable | Short — the limit is already crossed | Days to weeks when degradation is gradual |
| Unnecessary interventions | None | High | Moderate | Lower, if alert precision is managed |
| Setup effort | None | Low | Moderate | High — data pipeline plus triage process |
| Explains the decision | Not applicable | Policy document | Yes, deterministic | Evidence charts and contributing signals |
| Best suited to | Low-criticality, cheap, redundant assets | Regulated inspections, consumables | Well-understood single-cause failures | Critical assets with gradual, multi-signal degradation |
A realistic programme keeps preventive routines for statutory and consumable items, condition rules for well-understood limits, and applies AI to the small set of critical assets where downtime is expensive and degradation is visible in the data.
FAQ
For anomaly detection, roughly a year of continuous sensor history covering the normal operating cycle — enough to include seasonal and load variation. For failure prediction or RUL, you also need several recorded instances of the same failure mode on comparable assets, with dates and failure codes. Three documented failures across a fleet is a starting point; one is not.
The number of asset classes (each needs its own modelling work), the state of the data — clean historian and coded failure history is far cheaper than free-text notes and missing tags — whether new instrumentation is required, and the depth of CMMS integration. Ongoing cost is dominated by triage effort and periodic retraining, not by compute.
A data readiness assessment takes 2–4 weeks. A first asset class in shadow operation is typically 3–5 months, and meaningful precision figures need a further 2–3 months of real alerts and outcomes. Programmes that promise measurable downtime reduction in the first quarter are usually measuring something else.
Yes. Collection, storage, training and inference can all run inside the plant network, with no outbound connectivity. This is the normal configuration for utilities, energy and government assets in the UAE, and model updates for air-gapped sites are delivered as signed offline packages.
We report precision (how many alerts turned out to be real) and warning lead time per asset class, measured during shadow operation — not a headline accuracy percentage. False alarms are managed by calibrating thresholds to an agreed weekly alert budget, grouping related alerts into one case, suppressing known operating modes, and feeding every dismissed alert back with its reason so the next model version is better.
Yes, as custom development against your own instance. We read the asset hierarchy and maintenance history, create notifications or work orders from reviewed alerts with evidence attached, and read closure data back as training labels. We are not a certified partner of these vendors; the interfaces are engineered and documented as part of the project and handed over to you.
Not wholesale, and it should not. Statutory inspections and consumable replacements stay on schedule. What predictive AI can do is justify extending some intervals with evidence and catch the failures that the calendar plan was never going to see, for a defined set of critical assets.
You do. Data pipelines, model artefacts, training code, evaluation reports and integration source are handed over with the retraining runbook, and the historical data never leaves your control. We can operate and retrain the system under a support agreement, but the programme must be able to continue without us.
Then the first question is whether they justify instrumentation. For critical rotating equipment, adding vibration and temperature sensors is usually modest compared to the downtime cost. For the rest, route-based manual condition readings, runtime counters and good failure coding in the CMMS deliver more value than an unfunded sensor programme.
Do you have enough data for predictive maintenance?
Send us a list of assets, the sensors and tags you already record, and how failures are logged today. We reply with a written assessment: which assets are candidates now, which need instrumentation first, and where a simple threshold rule beats a model.
Request a Predictive Maintenance Data Readiness AssessmentSources & evidence
- IBM — Maximo Asset Management documentation — asset hierarchy, condition monitoring and work order APIs
- SAP Help Portal — product documentation (SAP S/4HANA Asset Management / Plant Maintenance) — notification and work order objects
- Odoo — official documentation (Maintenance and Manufacturing apps)
- OPC Foundation — OPC UA — standard interface to historian and control data
- ISO — ISO 55001 asset management — asset management system context for maintenance decisions
- NIST — AI Risk Management Framework
Vendor and product names are trademarks of their respective owners; references are for technical context and do not imply partnership, certification or endorsement unless stated on the vendor's official pages.