Ask a steel plant why the caster stopped, which assets are overdue for maintenance and what the last campaign cost to keep running, and production, maintenance and finance will each give a different answer. Each system is correct inside its own boundary, which is the problem. A unified operations data platform does not replace those systems. It gives them a shared asset model, shared time and shared event definitions. This guide explains how to design one and where a maintenance system like Oxmaint contributes.
Integration · Data Platform · Steel Plant Operations
Steel Plant Unified Operations Data Platform for Maintenance and Production
One asset model, one event timeline and one set of definitions, so maintenance, production and finance stop reconciling spreadsheets and start acting on the same record.
5Decisions: planning, reliability reviews, cost reviews, shutdown scope
4Shared models: asset hierarchy, event definitions, KPI definitions
3Integration: connectors, APIs, historian access, scheduled sync
2Source systems: CMMS, MES, SCADA, historian, ERP, quality
1Plant floor: sensors, drives, PLCs, equipment
The Same Stop, Told Four Ways
A single caster stop is recorded in different places with different vocabulary. The platform's first job is to make these records point at one event.
PLC and SCADA
Records a fault bit, a stop timestamp and a restart timestamp for a segment drive.
MES
Records a heat interrupted, a reason code selected by an operator and tonnes affected.
CMMS
Records a breakdown work order, labor hours, parts used and a failure cause after repair.
ERP
Records purchase orders, stock issues and cost postings against a cost center.
Why Steel Plants End Up With Disconnected Data
Cause 1
Different asset names
The automation tag says one name, the maintenance register another, and the ERP equipment number a third.
Cause 2
Different clocks
Systems timestamp events at different points, in different time zones or with unsynchronized clocks.
Cause 3
Different reason codes
Operators choose a stop reason from a short list. Technicians describe the cause in free text.
Cause 4
Different owners
OT, IT, production and maintenance each own a system and nobody owns the joins between them.
Cause 5
Different ages
A modern line, a legacy mill and a purchased unit all speak different protocols.
What Belongs on the Platform and What Stays Put
| Data domain | System of record | Shared on the platform | Maintenance and production value |
|---|---|---|---|
| Asset hierarchy | Maintenance system and engineering | Asset ID, parent, location, criticality | Every other record can be joined to the same equipment |
| Process signals | PLC, SCADA, historian | Selected tags and summaries, not every sample | Context for faults and condition-based jobs |
| Production events | MES | Stops, grade or product changes, campaign dates | Planned work scheduled around real production |
| Maintenance work | CMMS | Work orders, PM status, failure codes, labor and downtime-related work | History that explains why equipment stopped |
| Spares and stock | CMMS inventory and ERP | Part, quantity, location, lead time | Job readiness and shutdown planning |
| Cost and purchasing | ERP | Cost center, purchase order, receipt status | Maintenance cost per asset and per area |
| Quality outcomes | Quality system | Defect category linked to line and time | Connect equipment condition to product quality |
Build Order: Six Decisions in Sequence
1
Agree the asset model
Choose one asset ID scheme and one hierarchy depth. Cross-reference tag names and ERP equipment numbers to it, and give the register a single owner.
2
Define events once
Write down what counts as a stop, a planned stop, a breakdown and a changeover, and how each is timestamped.
3
Pick the first questions
Choose three questions the plant cannot answer today, such as repeat failures by line or maintenance cost per tonne by area.
4
Connect the minimum sources
Link only the systems needed for those questions. Prefer read-only and scheduled flows to begin with.
5
Publish shared definitions
Document how each KPI is calculated, from which fields, and who approves changes.
6
Review and extend
Check data quality monthly, retire unused feeds and add the next source only when a question needs it.
Start the Asset Model Where Maintenance Already Lives
A clean asset register is the foundation of every shared dataset. Build yours in Oxmaint, then connect production and process data to it.
Questions the Unified Platform Should Answer
If a platform cannot answer questions like these, it is a data store, not an operations tool.
Maintenance planner
Which assets on the rolling line have overdue PMs, and when is the next planned production gap?
Production manager
How much of last month's lost time was equipment failure, and which assets caused most of it?
Reliability engineer
Which failure modes repeat on similar drives, and what was running when they failed?
Storekeeper
Which critical spares are below their minimum, and which planned jobs need them?
Plant finance lead
What did maintenance spend by area, split into planned and unplanned work?
Turnaround manager
Which backlog items on this unit should be done during the next outage?
Governance: Who Owns What
| Item | Owner | Consulted | Review cadence |
|---|---|---|---|
| Asset IDs and hierarchy | Reliability or asset management lead | Automation, production, finance | On every change, with a quarterly audit |
| Event and reason definitions | Operations excellence lead | Production, maintenance | Quarterly |
| Source connections | Plant IT and automation | Cybersecurity, vendors | With each system change |
| KPI definitions | Plant manager or delegate | All function heads | Twice a year |
| Data quality checks | Named data steward | System owners | Monthly |
Security and Safe Data Movement
- Move data out of the control network through read-only paths, with no write-back into automation systems.
- Hold the shared platform in a segmented zone, so neither OT nor business networks reach into each other directly.
- Give each connector the narrowest account it needs, and record who can see which dataset.
- Keep the maintenance system of record authoritative for work history, so corrections happen once at the source.
Maturity Ladder
Stage 1: Siloed
Each system holds its own truth. Reports are rebuilt manually in spreadsheets.
Stage 2: Cross-referenced
Asset IDs are mapped across systems, and a few joined reports exist.
Stage 3: Shared model
Events and KPIs have common definitions, with scheduled feeds between systems.
Stage 4: Acting on data
Signals trigger work, schedules respond to production and reviews use the same record.
What Oxmaint Contributes to the Platform
Asset register A structured hierarchy with criticality that other datasets can reference.
Work order history Corrective, preventive and inspection records with failure codes and labor.
Preventive schedules Calendar, meter and condition-based plans linked to assets.
Inventory Parts, stock levels and reorder rules tied to equipment.
Mobile capture Technicians record findings, readings and completions at the asset.
Dashboards and reports Backlog, compliance and cost views built from consistent fields.
Integration Patterns Compared
Plants combine patterns over time. The right mix depends on how many systems you have and how often each one changes.
| Pattern | How it works | Best for | Limits |
|---|---|---|---|
| Point-to-point interfaces | Each pair of systems exchanges data directly | One or two critical connections | Becomes hard to maintain as the number of systems grows |
| Integration layer or middleware | Systems connect once to a central layer that routes and translates | Plants with many systems and changing versions | Needs an owner and a clear change process |
| Historian-centered | Process and event data is gathered in the historian and read from there | Time-series heavy questions | Business context such as work orders and costs sits elsewhere |
| Shared data store with interfaces | Selected data from each source is copied into a common store with shared definitions | Cross-functional reporting and analytics | Copies can drift, so refresh rules and quality checks matter |
| Event-based messaging | Systems publish events that others subscribe to | Faults, stops and status changes that need fast action | Event names and payloads must be governed |
Five Use Cases That Justify the Effort
Use 1
Maintenance around production
Planned jobs scheduled into real gaps in the production plan, instead of guessed windows.
Use 2
Repeat failure analysis
Work history joined to operating conditions, so repeated failures can be linked to what the line was doing.
Use 3
Cost by area and asset
Maintenance spend rolled up from work orders and purchasing to the same hierarchy production uses.
Use 4
Outage readiness
Backlog, spares and labor viewed together, before the shutdown scope is frozen.
Use 5
Condition-triggered work
Signals from automation turned into inspections or work orders, with the history attached.
Data Quality Rules Worth Automating
| Rule | What it checks | Example failure | Who fixes it |
|---|---|---|---|
| Asset exists | Every event or work order points to a valid asset ID | A stop recorded against a retired equipment code | Asset register owner |
| Time is consistent | Timestamps are in one time standard and within a sensible range | A work order closed before it was opened | System owner |
| Reason is coded | Stop and failure reasons come from the agreed list | A free-text reason where a code is required | Shift supervisor |
| No orphan records | Parts, costs and labor link to a job and an asset | Stock issued with no work order | Storekeeper and planner |
| Duplicates are merged | One physical event produces one record per system | The same breakdown logged twice by two shifts | Planner |
A 90-Day Starting Plan
Days 1 to 15
Choose the pilot line, name the owners and agree the first three questions. Audit the asset list for that line.
Days 16 to 45
Set the asset ID scheme and event definitions, then connect the minimum sources in read-only mode.
Days 46 to 75
Publish the first joined views, run the data quality rules and fix the top causes of bad records.
Days 76 to 90
Review whether the three questions are answered, record the lessons and plan the next line.
Pitfalls to Avoid
- Starting with technology selection before the asset model and definitions are agreed.
- Copying every tag and table into a central store, then discovering that nobody uses most of it.
- Letting each department publish its own version of the same KPI.
- Assigning the project to IT alone, or to operations alone, rather than to a joint team.
- Treating the first release as finished, with no owner for the data after go-live.
- Writing data back into control systems when read-only access would meet the need.
One Dataset, Different Views by Role
Operator and shift lead
Current stops, open jobs on their line and any permits that affect the next few hours.
Technician
Assigned jobs, the asset history, attached trends and the parts reserved for the task.
Planner and scheduler
Backlog by asset and craft, upcoming production gaps and job readiness status.
Reliability engineer
Failure modes by equipment class, repeat events and condition data around each failure.
Department head
Planned versus unplanned work, PM compliance and cost by area against budget.
Plant leadership
A short set of agreed KPIs, each with a definition that every function accepts.
Bringing Legacy and Acquired Plants Into the Model
Many steel groups run plants of different ages, vendors and naming habits. Standardize the model first, and connect the technology second.
- Map each plant's asset codes to the common hierarchy using a cross-reference table, rather than renaming everything at once.
- Agree a short list of mandatory fields that every site must provide, and allow optional fields for local needs.
- Start with sites that already use a maintenance system with consistent records, and bring the others in as their data improves.
- Keep the local language of technicians in notes, but require coded values for failure and action fields.
- Compare plants only on KPIs that are defined the same way, and say so on every comparison report.
Measuring Whether the Platform Is Earning Its Place
| Measure | How to read it | Warning sign |
|---|---|---|
| Questions answered without manual work | Share of the agreed first questions answered from the platform alone | People still rebuild the same reports in spreadsheets |
| Asset match rate | Records from each source that match a valid asset in the shared model | A growing pile of unmatched events and costs |
| Data freshness | Delay between an event in the source system and its appearance on the platform | Feeds failing silently, with nobody alerted |
| Active users by role | Which roles open and use the shared views | Only the project team uses it |
| Decisions linked to data | Reviews, schedules and purchases that cite a platform view | Meetings still run from private files |
Questions to Settle With Plant IT and Automation Early
- Which systems may be read, by whom, and through which approved network path?
- Who patches, monitors and documents each connector after the project team has moved on?
- How will a change to a source system, such as a version upgrade, be tested against the shared model?
- What is the retention period for each dataset, and who approves deletion?
Frequently Asked Questions
Does a unified platform mean replacing our MES or ERP?
No. Each system stays the record for its own domain, while the platform aligns identifiers, events and definitions between them.
Where should a steel plant start?
Start with the asset hierarchy and three business questions, then connect only the sources needed to answer them. Book a demo to scope a first phase.
How is this different from a data lake?
A data lake stores data. A unified operations platform adds shared definitions, ownership and links back into work, so insight becomes action.
Do we need every sensor tag on the platform?
No. Share the tags and summaries that answer maintenance and production questions, and keep full-rate data in the historian.
How does Oxmaint help the platform effort?
It provides the asset register, work history, PM and inventory records that other data joins to. You can start free and build that foundation.
One Plant, One Record of What Happened
Connect maintenance, production and enterprise data around one asset model and give every team the same facts to work from.
