Equipment state data is usually the time-based backbone for production KPIs. States like RUN and IDLE are used to segment the clock into “value-adding” vs “non-value-adding” time, which then feeds metrics such as OEE, utilization, and non-productive time (NPT). The exact impact, however, depends heavily on how states are defined, captured, and mapped in your systems.
Typical mapping of states into time buckets
In many regulated and industrial environments, equipment states are mapped to a small number of KPI time buckets:
- Run / Productive (often RUN): counted as value-adding time when the machine is producing in-spec product at the intended rate.
- Planned stop (e.g. SETUP, CHANGEOVER, CLEANING, PREVENTIVE_MAINT): may be treated as excluded time or as a separate KPI bucket, depending on your OEE and scheduling philosophy.
- Unplanned stop (e.g. FAULT, DOWN, JAM, NO_MATERIAL): usually feeds unplanned downtime, reliability, and availability losses.
- Idle / Waiting (e.g. IDLE, STARVED, BLOCKED, NO_OPERATOR): often treated as non-productive but distinguishable from hard failures.
- Off / Not scheduled (e.g. OFF, POWER_DOWN, NO_SCHEDULE): typically excluded from OEE and related KPIs but may be tracked for asset utilization or capital productivity.
The same physical state can be mapped differently by different plants or systems. For example, some sites treat setup as planned downtime that is excluded from OEE, while others include it as an efficiency loss.
How RUN and IDLE feed core KPIs
Below are common KPI calculations and how RUN/IDLE time segments are typically used. These examples assume state data is complete and validated; real results depend on your specific configurations.
- Availability (part of OEE)
Availability is usually calculated as:
Availability = (Run time) / (Planned production time)
Here, RUN contributes directly to the numerator. IDLE, unplanned DOWN, and other non-running states within planned time reduce availability.
- OEE (Overall Equipment Effectiveness)
OEE is typically:
OEE = Availability × Performance × Quality
States impact primarily the Availability component via the split between RUN and non-RUN during planned time. If your model includes certain planned stops in availability, IDLE and setup may reduce OEE; if excluded, they affect separate KPIs instead.
- Utilization / Asset use
Commonly expressed as:
Utilization = (Time asset is in RUN state) / (Total calendar time or total scheduled time)
IDLE time shows underutilized capacity and can be broken down by cause (no work, no operator, maintenance, etc.) if you maintain cause codes or sub-states.
- Non-Productive Time (NPT)
NPT aggregates all non-RUN states within a chosen window:
NPT = IDLE + DOWN + BLOCKED + STARVED + other non-productive states
IDLE is a major contributor here. Plants often split NPT into controllable vs non-controllable buckets (e.g. no material vs regulatory hold) for prioritization.
- Schedule adherence / on-time completion
RUN vs IDLE patterns explain why a work order finished early or late. For example, long IDLE with root causes in “no quality release” or “waiting for inspector” points to systemic issues beyond pure equipment reliability.
Why definitions and mappings matter
In brownfield environments, the same “RUN” and “IDLE” labels can mean very different things across lines, plants, or vendors. This can materially distort aggregated KPIs if not normalized.
- Different PLC/SCADA conventions: One line may drop into IDLE whenever an operator opens a guard door; another may flip to a specific SAFETY_STOP state.
- MES vs historian vs CMMS variance: Your MES might roll up several low-level codes into RUN, while the historian exposes them separately. If a KPI uses one source for state duration and another for production counts, discrepancies appear.
- Human-entered overrides: Operators may reclassify events (e.g. from DOWN to IDLE) to avoid blame or to match an interpretation of “what really happened.” Without controls, this shifts time between KPI buckets and can hide chronic issues.
Before using state-based KPIs for decisions, most regulated plants need a clear, documented mapping from raw equipment states to KPI categories and evidence that the mapping is stable and version-controlled.
Handling mixed and legacy systems
In long-lifecycle, regulated environments, it is rare to have a single, clean definition of RUN and IDLE across all assets. You are likely dealing with:
- Older equipment with only a few digital signals (e.g. simple RUN/STOP) that require assumptions for IDLE vs failure.
- Newer machines with dozens of sub-states that need to be collapsed into standard KPI categories.
- Separate MES, historian, and CMMS systems, each with partial or inconsistent state coverage.
Because full system replacement is often impractical due to qualification and downtime risk, many organizations standardize KPI logic in a layer above plant-floor systems. This typically involves:
- Defining a canonical set of KPI state categories (e.g. Productive, Planned Stop, Unplanned Stop, Idle/Waiting, Not Scheduled).
- Mapping each machine/vendor-specific code into those categories, with documented rules and change control.
- Maintaining audit trails for mapping changes, so historic KPIs remain interpretable during audits and investigations.
Common pitfalls and failure modes
Several recurring issues affect how RUN and IDLE influence KPIs:
- State flapping: Rapid oscillation between RUN and IDLE due to noisy signals or misconfigured thresholds can inflate downtime and distort NPT. Debounce logic or minimum-duration rules are often needed.
- Missing transitions: Communication drops between PLCs, SCADA, and MES can create gaps. Some systems backfill based on last known state, which may artificially extend RUN or IDLE durations.
- Ambiguous IDLE: If IDLE is used for every non-running condition, root cause analysis is impossible. Breaking it into sub-codes (e.g. waiting for material, waiting for QA, waiting for setup) is important for actionable KPIs.
- Inconsistent planned/unplanned logic: If some teams mark changeover as planned stop and others treat it as downtime, cross-site comparisons of OEE and utilization are unreliable.
- Lack of traceability: When mapping logic or meanings of states change without version control, historical KPI trends are difficult to defend during audits or management reviews.
Practical steps to use RUN/IDLE states reliably
To make equipment-state-based KPIs credible in regulated operations:
- Document clear definitions for RUN, IDLE, and other states in a standard reference, separate from individual vendor manuals.
- Implement and maintain a mapping from raw machine/PLC codes to KPI categories with formal change control and review.
- Validate state capture and KPI calculations against known scenarios (e.g. timed test runs, shadow logging) before relying on them for improvement initiatives or audit evidence.
- Regularly review outliers and anomalies where production counts and state-based times appear inconsistent.
- Train operators and maintenance on when and how state overrides or manual entries are allowed, and log those changes for traceability.
With these controls in place, RUN and IDLE become more than simple status flags; they are structured inputs that can support defensible, plant-wide KPIs in complex, mixed-system environments.
