A dashboard can show a large OEE number and still fail the production team. The problem is usually not the chart. It is the event dictionary behind the chart: what counts as planned time, how a yarn break is recorded, whether a changeover is downtime, who closes an alarm and which clock is trusted when a machine stops.
For a circular knitting factory, OEE downtime coding is a practical data-governance project. The goal is not to promise a universal improvement percentage. The goal is to create a shared language that production, maintenance, quality and software teams can use to identify loss, assign ownership and select the next action.
What OEE coding should accomplish
A useful coding system should answer five questions for every stop or speed loss:
- When did the event begin and end?
- Was the time planned, unplanned or a performance loss?
- What physical condition caused the event?
- Which team owns the next action?
- What evidence supports the selected reason code?
Use these questions to connect the dashboard with the machine log, work order, quality record and shift report. If operators are forced to choose from dozens of similar labels, they will select “other” and the dashboard will become a polished guessing system.
The factory should first review existing circular knitting machine maintenance software and CMMS workflows and condition monitoring checks. OEE coding should complement those records, not create a second disconnected maintenance database.
Start with a KPI boundary document
Before configuring a dashboard, write a one-page boundary document. It should define:
| Boundary | Decision to document |
|---|---|
| Asset | Machine ID, gauge, diameter, line or cell |
| Calendar | Shift pattern, breaks, holidays and planned maintenance |
| Production time | Scheduled, available, running and net running time |
| Quality | Accepted output, rework, scrap and inspection delay |
| Data owner | Production, maintenance, quality or IT |
| Time source | PLC, gateway, HMI, MES or manual confirmation |
| Calculation | Version of formulas and rounding rules |
ISO 22400 is a useful reference for manufacturing KPI terminology, but it does not remove the need for factory-specific definitions. A 20-minute planned cleaning interval can be treated differently from an unexpected jam. The choice must be documented and applied consistently.
Build a three-level downtime dictionary
A practical dictionary normally has a small number of level-one families, a manageable set of level-two causes and optional level-three detail. The exact labels should reflect the factory’s machines and maintenance process.
| Level one | Level two examples | Evidence or owner |
|---|---|---|
| Planned time | Shift break, scheduled cleaning, approved changeover | Production plan |
| Mechanical | Cylinder alignment, cam wear, bearing, belt or coupling | Maintenance work order |
| Needle and sinker | Broken needle, damaged sinker, hook inspection | Quality or maintenance record |
| Yarn and feeder | Yarn break, feeder setting, tension variation, package issue | Operator and feeder check |
| Electrical and control | Drive alarm, encoder fault, sensor fault, PLC or HMI | Alarm log and technician note |
| Material and quality | Yarn lot hold, fabric defect, inspection rejection | Quality record |
| Utilities | Power quality, compressed air, cooling or network | Utility or engineering log |
| Supply and support | Missing part, waiting for technician, approval delay | Purchase or service record |
| Unknown | Temporary code with review deadline | Shift supervisor |
Do not use “machine stopped” as the final reason. That is a symptom, not a cause. Use it only as an initial automatic event until the operator or technician confirms the root category.
Define planned versus unplanned time
The same activity can be planned on one shift and unplanned on another. A scheduled needle inspection belongs in planned time when it is in the approved production schedule. An inspection triggered by repeated breakage may be an unplanned quality or maintenance event. The dashboard should preserve both the automatic stop and the final classified reason so supervisors can audit changes.
Changeovers require a written rule. If a product change is scheduled, its standard duration can be planned. Any time beyond the standard should become an unplanned changeover overrun or a specific cause such as missing yarn, tooling or approval. This separation reveals whether the problem is the process standard or execution.
Design the event capture flow
A reliable flow combines automatic signals with human classification:
- The gateway records a machine-state transition with a timestamp.
- A short stop is automatically classified when a trusted signal exists.
- For longer stops, the HMI asks the operator for a reason family.
- The supervisor can correct the code before shift close.
- Maintenance attaches a work-order number for technical causes.
- The dashboard locks the final code but retains the audit history.
Use one authoritative clock. If the PLC uses local time and the MES uses UTC, a stop can appear in the wrong shift or be counted twice. Record the source timestamp, ingestion timestamp and timezone conversion. Network outages should create a data-quality flag rather than silently filling gaps.
Dashboard requirements for production teams
A manager needs a different view from a technician. Specify acceptance views before buying software.
Shift view
Show scheduled time, running time, stop minutes, top three causes, output and accepted output. Allow a supervisor to open the reason-code detail behind each bar.
Machine view
Show a time line of state transitions, alarm codes, operator corrections, work orders and repeat events. A machine with a high OEE value but repeated short stops should not disappear behind an aggregate.
Pareto view
Rank loss minutes by cause, machine, product, yarn lot and shift. Include count and duration; ten short feeder stops may require a different response from one long part shortage.
Data-quality view
Show unknown codes, duplicate events, missing timestamps, stale machine connections and manual edits. A dashboard without data-quality visibility encourages false confidence.
Review view
Compare the current dictionary against the previous version. A changed label can break trend analysis, so retain a version number and a mapping table.
Supplier evaluation checklist
| Requirement | Evidence to request | Acceptance question |
|---|---|---|
| Connectivity | Supported PLC, gateway and MES interfaces | Can the system preserve raw events? |
| Reason codes | Hierarchy editor and version history | Can labels be changed without losing history? |
| Time handling | Timezone, buffering and outage behavior | What happens during a network outage? |
| User control | Role permissions and approval workflow | Who can edit a closed shift? |
| Maintenance link | CMMS or work-order integration | Can a stop open or reference a work order? |
| Reporting | Machine, shift, product and cause filters | Can operators drill from KPI to event? |
| Export | API, CSV or database access | Can the factory retain its data? |
| Support | Training, response time and documentation | Who maintains the dictionary after go-live? |
Do not accept a demonstration using only a perfect sample dataset. Ask the supplier to import a day containing short stops, a planned changeover, a missing timestamp and an unknown reason. The system’s response to imperfect data is part of the buying decision.
Implementation phases
Phase 1: Baseline
Select a small representative group of machines. Export current shift reports, alarm logs and work orders. Do not change the production definition before understanding the existing data.
Phase 2: Dictionary workshop
Bring operators, maintenance, quality, engineering and IT together. Limit the first version to reasons that can be observed or verified. Assign an owner and review date to every code.
Phase 3: Pilot
Run the dictionary beside the current process for a defined period. Compare automatic events with operator classifications and investigate the top unknown codes.
Phase 4: Acceptance
Test calculations, permissions, timezones, event buffering, exports and dashboard filters. Sign off only when the factory can reproduce a sample calculation from raw events.
Phase 5: Governance
Review code performance monthly. Retire unused labels, merge duplicates and add new causes only with version control. Never change a definition silently in order to improve a trend line.
Avoiding false OEE conclusions
OEE is sensitive to the planned-production boundary, standard cycle assumptions and quality definitions. A higher number can result from excluding difficult products or reclassifying stops, not from a real process improvement. Publish the formula, data window and exclusions with every management report.
Any financial benefit should be modelled from the factory’s baseline: recovered minutes, accepted output, labor, energy, scrap and sales constraints. A dashboard vendor’s generic ROI percentage is not a substitute for these records.
FAQ
Is an OEE dashboard the same as an MES?
No. OEE is a performance measurement layer. An MES may manage production orders, genealogy, quality, labor and execution workflows. The two can integrate but should not be treated as identical.
Should operators enter every short stop?
Not necessarily. Automatic signals can capture short events, while the operator confirms longer or ambiguous stops. The rule should be tested against the factory’s actual stop pattern.
How many reason codes should the first version contain?
Use the smallest set that distinguishes action paths. Add detail after the pilot shows a real need; a long unowned list reduces data quality.
Can ISO 22400 provide the complete dictionary?
No. It provides KPI context. The factory still needs its own asset boundaries, reason hierarchy, timestamp rules and approval workflow.
Conclusion
A circular knitting machine OEE downtime coding dashboard succeeds when the underlying event language is trusted. Define the calendar, separate planned and unplanned time, use a short reason hierarchy, preserve raw events, connect technical causes to work orders and expose data quality. The result is a decision tool that supports maintenance and production instead of merely displaying a score.
References
This reference provides the standard context for measurable manufacturing operations indicators and KPI definitions.
This industry source describes automation, digitalisation, smart-factory and data-driven production themes in textile machinery.
This report provides current industry context for AI and machine-learning discussions in textile manufacturing.
This article illustrates how machinery, software, data and services are being discussed together in circular knitting.
This guidance is relevant to access control, asset visibility and change management when machine data is connected to plant systems.