A steel plant already produces the data needed for better maintenance decisions: historian time series, PLC events, work orders, inspection forms, oil reports, shutdown plans and spare part movements. The problem is that each lives in its own system with its own naming. A maintenance data lake brings them together for analysis, but without rules it becomes a swamp that nobody trusts. This guide covers zones, keys, governance and sequencing, and how Oxmaint maintenance management software supplies the structured maintenance record at the center.
Steel Plant Maintenance Data Lake Strategy
Build a Maintenance Data Lake That Stays Clean and Useful
Collect raw plant data once, clean it in stages and publish trusted datasets tied to a single asset register, so analysts and models start from reliable ground.
SourcesHistorian, PLC, CMMS, ERP, inspections, oil lab
Raw zoneStored as received, never edited
Cleaned zoneUnits, time stamps, asset IDs, quality flags
Curated zoneJoined, documented datasets for reliability and AI
Serving layerDashboards, models, alerts, CMMS actions
The questions a connected maintenance dataset can answer
A data lake is not the goal. It is a way to answer questions that no single system can answer alone.
Q1Which vibration or temperature patterns appeared before past bearing failures on this equipment type?
Q2How does maintenance cost per tonne change with product mix, load and equipment age?
Q3Which repairs fixed the problem, and which were followed by a repeat failure soon after?
Q4Are spare part holdings aligned with the failures that actually occur?
Q5Which preventive tasks find real defects, and which only consume hours?
What to bring in, and who owns it
Start with sources that directly answer your priority questions. Each source needs an owner, a refresh pattern and a way to link to the asset.
| Source | Typical content | Refresh pattern | Key to link to assets | Main quality risk |
|---|---|---|---|---|
| Process historian | Time series from sensors and controllers | Continuous or batch | Sensor tag mapped to asset | Drift, gaps, changed scaling |
| CMMS or maintenance system | Assets, work orders, inspections, failure codes, labor, parts | Frequent increments | Asset code | Missing causes, generic assets |
| Condition monitoring systems | Vibration spectra, thermal readings, alerts | Continuous or scheduled | Measurement point linked to asset | Duplicate alerts, unmapped points |
| Lab and oil analysis | Sample results and condition ratings | As results arrive | Sample point linked to asset | Irregular sampling, mislabeled samples |
| ERP and inventory | Part numbers, stock, purchases, costs | Daily | Part linked to asset or bill of materials | Inconsistent item naming |
| Production and quality systems | Schedules, grades, downtime reasons, output | Per event or shift | Unit or line, mapped to assets | Different downtime vocabulary |
| Shutdown and project plans | Scope, durations, actual work and deferrals | Per outage | Asset or task code | Plans kept in separate spreadsheets |
What happens in each zone
Raw
Keep it exactly as received
Store original files and records with load time and source name. Never overwrite them, so any later cleaning step can be repeated or audited.Cleaned
Standardize and flag
Convert units, align time zones and clocks, map tags to asset IDs and mark suspect values with quality flags instead of deleting them.Curated
Publish documented datasets
Join sources into purpose-built tables such as failure events with preceding sensor history, with a description, owner and refresh schedule.Serving
Deliver to people and systems
Feed dashboards, models and alert rules, and send findings back to the maintenance system as inspections and work orders.Keep the Maintenance Record at the Center
Capture structured assets, work orders, inspections and parts in one system, so every data project starts from consistent maintenance history.
The asset ID is the join key for everything
Most integration failures come from unclear identifiers. Decide early what links one dataset to another, and publish the rules.
Core keys
- Asset ID from the maintenance system as the master identifier
- Sensor tag to asset mapping table with start and end dates
- Part number to asset or bill of materials link
- Work order ID that ties failures, labor, parts and findings together
- Failure code lists shared across systems
Data contracts to agree with each source owner
- Which fields are delivered and in what format
- How often data is refreshed and how late it may be
- What happens when a field, tag or code changes
- Who is notified when quality checks fail
- How corrections and late records are handled
Match storage detail to how the data will be used
Keeping every sample forever is expensive and often unnecessary. Tier the data by value and by the question it supports.
| Data tier | Detail level | Suitable for | Retention approach |
|---|---|---|---|
| Hot | Full resolution recent data | Active alerts, diagnosis, model scoring | Weeks to months on fast storage |
| Warm | Summaries such as averages, peaks and features | Trend analysis and model training | Months to years in the lake |
| Event windows | Full resolution around failures and alarms | Learning fault signatures | Keep long term, since they are rare and valuable |
| Cold | Compressed archive of raw data | Audits and rebuilds | Per policy and regulation, on low cost storage |
Rules that stop a lake from turning into a swamp
CatalogEvery dataset has a name, description, owner, source, refresh rate and known limits.
Quality checksAutomated tests for completeness, ranges, duplicates and mapping coverage, with alerts to the data owner.
Access controlRole-based access, with sensitive operational data protected and operational technology networks kept separate under plant policy.
LineageTrack where each curated field came from, so a figure in a report can be traced to its sources.
Change controlRecord changes to tags, codes and transformations, and notify users of datasets that depend on them.
Review cycleRetire unused datasets and check usage and quality at a fixed interval.
Start small, prove value, then widen the lake
1
Pick two or three questions
Choose questions tied to cost or downtime on a critical asset class, and name the sponsor who will use the answers.2
Fix identifiers first
Clean the asset register and map sensor tags before loading any history.3
Load the minimum sources
Bring in the maintenance system, the relevant sensors and failure records for the chosen assets.4
Publish one curated dataset
For example, failure events joined with the sensor history before each failure, fully documented.5
Act and measure
Use the dataset in a model or report, send findings to work orders and measure the result before extending.Mistakes that make maintenance lakes fail
| Pitfall | What it causes | Prevention |
|---|---|---|
| Loading everything before asking a question | High cost and no clear value | Start with specific use cases and scope sources to them |
| Skipping asset mapping | Time series cannot be tied to equipment history | Map tags to assets before analysis |
| Editing raw data | No way to audit or rebuild | Keep raw immutable and clean in later zones |
| No data owner | Quality problems persist unnoticed | Assign an owner for each source and dataset |
| Treating the lake as a CMMS replacement | Technicians still lack a daily workflow | Keep execution in the maintenance system and analysis in the lake |
| Ignoring time synchronization | Events and signals do not line up | Use a common time source and record time zones |
What stays in the maintenance system and what lives in the lake
Maintenance system
- Asset register and hierarchy
- Work orders, inspections and scheduling
- Mobile entry in the field
- Inventory and parts issue
- Compliance records and sign-offs
Data lake
- Long-term sensor and event history
- Cross-system analysis and model training
- Large-scale trend and cost studies
- Curated datasets for reliability work
- Archives for audits and rebuilds
How Oxmaint helps
- Structured asset management and failure data as a clean source for the lake
- Work orders and inspections that receive findings from analytics
- Reporting and dashboards for maintenance KPIs by area and asset
- Inventory linked to equipment for spare part analysis
Use cases that justify the effort
Choose use cases where connected data changes a decision. Each one below needs maintenance records plus at least one other source.
| Use case | Data combined | Output | Who benefits |
|---|---|---|---|
| Failure precursor analysis | Failure events, sensor history, operating state | Signal patterns that appear before each failure mode | Reliability engineers and model builders |
| Preventive task effectiveness | Task completion, findings, later failures | List of tasks that find defects and tasks that do not | Planners and maintenance managers |
| Spare parts optimization | Part usage, failures, lead times, criticality | Stock levels matched to real failure patterns | Storekeepers and procurement |
| Maintenance cost per tonne | Work order cost, production output, product mix | Cost trends by line and product | Plant management and finance |
| Outage planning accuracy | Planned scope, actual work, deferred items, durations | Better duration estimates and scope control | Shutdown planners |
| Energy and reliability links | Energy readings, equipment condition, repairs | Equipment where poor condition raises energy use | Energy and maintenance teams |
Automated tests that protect trust in the lake
Quality checks should run every time data loads, and failures should alert the data owner. Start with a small set that catches the most common problems.
Mapping coverageShare of sensor tags and work orders that link to a valid asset ID.
CompletenessExpected records and fields present for each source and period.
Range and unit checksValues inside physical limits, with consistent units across sources.
Duplicate detectionRepeated records, double-loaded files and duplicate asset entries.
Time consistencyTime stamps in order, in a known time zone and close to other systems.
Referential checksFailure codes, part numbers and asset IDs exist in their master lists.
Bridging operational technology and business IT carefully
Plant networks protect production, so data movement toward a lake needs deliberate design. Involve security and operations early.
Design principles
- Use controlled gateways or one-way transfers from plant networks
- Copy data out, and never write analytics results directly into controllers
- Apply least-privilege access by role and dataset
- Encrypt data in transit and at rest under company policy
- Log access to sensitive datasets
Ownership model
- Source owners guarantee the content and meaning of their data
- A data steward maintains catalog entries and quality rules
- Reliability engineering owns curated maintenance datasets
- IT or data teams run the platform and its security
- A steering group reviews priorities and retires unused datasets
Controlling cost
- Store summaries for long periods and keep full resolution only around events.
- Delete or archive datasets nobody has used in a set period.
- Load sources in response to use cases, not in advance of them.
- Track storage and processing cost by project so sponsors see the trade-off.
Examples of curated datasets worth publishing first
Curated datasets are where the value is delivered. Each one should answer a defined question and be documented well enough for a new analyst to use without help.
| Dataset | Contents | Primary users |
|---|---|---|
| Failure events with sensor context | Each failure with the signals, operating state and maintenance history before it | Reliability engineers and model builders |
| Asset reliability summary | Failures, downtime, repair hours and cost per asset and period | Maintenance management |
| Preventive task outcomes | Task completion, findings recorded and follow-up work generated | Planners and reliability engineers |
| Spare part consumption | Parts used per asset, lead times and stock position | Storekeepers and procurement |
| Outage scope and results | Planned tasks, actual durations, deferred and added work | Shutdown planners |
Skills the team needs
- A reliability engineer who understands failure modes and can validate findings.
- A data engineer to build pipelines, quality checks and the catalog.
- An analyst or data scientist for models and cross-system studies.
- A maintenance planner who can turn results into scheduled work.
- An OT and security contact to approve data paths from the plant network.
A realistic roadmap for the first year
1
First quarter: foundations
Agree use cases, name owners, clean the asset register, map tags for one asset class and set up the raw and cleaned zones.2
Second quarter: first dataset
Publish the failure events dataset, build quality tests and document it in the catalog for users.3
Third quarter: first decisions
Use the dataset for a model or report, send findings to the maintenance system and measure the effect on planned work.4
Fourth quarter: extend with discipline
Add the next asset class or source based on results, retire unused data and review governance and cost.Judge the lake by decisions improved, not terabytes stored
- Use cases in production: how many curated datasets support a live report, model or alert.
- Active users: number of analysts and engineers using curated datasets each month.
- Time to answer: days needed to answer a new maintenance question that needs data from several systems.
- Mapping coverage: share of sensor tags and work orders linked to valid assets.
- Quality test pass rate: share of loads that pass automated checks without manual repair.
- Action rate: share of findings that became inspections or work orders in the maintenance system.
Maintenance data lake questions
Do we need a data lake to start predictive maintenance?
Not always. Begin with clean assets and records for one asset class, and add a lake when you need cross-system history at scale.Should the lake replace our historian?
Usually not. The historian serves real-time operations, and the lake adds long-term, joined and curated data for analysis.How do we keep operational networks secure?
Follow plant policy, separate networks and use controlled one-way or gateway transfers, with security teams involved from the start.What is the most important first dataset?
Failure events with sensor history before each event, tied to clean assets. You can book a demo to see structured failure records.Where should maintenance data quality begin?
At the source. Set up structured work orders and assets in Oxmaint so downstream data is consistent.Start Your Data Strategy With Better Maintenance Records
Build the asset register and work order foundation that every lake, model and dashboard depends on.
