ISO 22400 KPIs assume that every equipment resource has a clear, time-based history of states (e.g., producing, setup, idle, failure). Modeling equipment state events is about making that history explicit, consistent and queryable across heterogeneous equipment and systems.
1. Start from a canonical state model, not vendor tags
Do not model states directly from each machine’s native status bits or OEM naming. Instead, define a canonical state model for your site that is aligned to ISO 22400 notions of:
- Operating / producing (planned production, good parts, may include controlled rework)
- Planned downtime (scheduled maintenance, planned changeover, planned breaks)
- Unplanned downtime (failures) (breakdowns, safety stops, unplanned maintenance)
- Setup / changeover (if modeled separately from planned downtime)
- Idle / starved / blocked (equipment available but not producing)
- Testing / calibration / qualification (often non-productive but planned and required)
Use this canonical model as the target and then map equipment-specific signals into it. ISO 22400 leaves room for site-specific detail; the critical point is consistency across assets so KPI calculations remain comparable.
2. Represent states as time-bounded events
For KPI calculation, each state must be represented as an event with:
- Equipment identifier (logical resource, not just a PLC address)
- State code (from your canonical model)
- Start timestamp (ideally from a synchronized time source)
- End timestamp (or an explicit “open” marker until the next state)
- Origin / source (SCADA, MES, manual, CMMS, etc.)
- Reason / cause code where applicable (for downtime, reduced speed, planned vs unplanned)
ISO 22400 KPIs like availability, performance and OEE rely on aggregating state durations over a time window. That aggregation breaks down if events do not have well-defined start and end times.
3. Enforce “one active state per resource”
To avoid ambiguous KPI calculations, model states so that for any point in time and any given resource:
- There is at most one active primary state (e.g., operating, planned downtime, failure, idle).
- Optional secondary attributes (e.g., reason codes, product, order) are attached to that primary state, not modeled as separate overlapping primary states.
In practice this means you need logic in your MES/event processor to:
- Terminate the previous state when a new primary state starts.
- Detect and resolve overlaps coming from different systems (e.g., SCADA vs CMMS vs operator terminals).
- Handle “unknown” or “undefined” states explicitly if data is missing.
Overlapping primary states are a common failure mode when integrating multiple legacy systems and will lead to double-counted or under-counted time in ISO 22400 KPIs.
4. Separate “what” (state) from “why” (reason)
For analysis of losses, model the “what” and “why” distinctly:
- The state captures the high-level category aligned to ISO 22400 (e.g., “unplanned downtime”).
- The reason code captures the specific cause (e.g., “tool breakage”, “material shortage”, “operator not available”).
Reason codes can be hierarchical and site-specific, but should be governed under change control, because they directly impact KPI interpretations and trend analysis over multi-year equipment lifecycles.
5. Define clear rules for planned vs unplanned time
ISO 22400 KPIs depend heavily on how you distinguish planned from unplanned time. Your model should include explicit rules, typically configured in MES or scheduling systems:
- Link planned downtime to the site’s production calendar, shift patterns, and planned maintenance windows.
- Ensure triggers from the CMMS (e.g., planned PM) are correctly mapped to planned states, not failures.
- For changeovers, decide whether you treat them as planned downtime or as a distinct category and apply that consistently.
If calendar or planning data is unreliable or not integrated, you will struggle to compute ISO 22400 KPIs consistently across lines and plants.
6. Explicit modeling of reduced speed and microstops
For performance-related ISO 22400 KPIs, you need to model:
- Operating at nominal speed
- Operating at reduced speed
- Frequent, short stops (microstops), if your measurement granularity and process justify it
There are two common patterns:
- State-based: distinct states for “operating” vs “reduced speed” vs “microstop” (with minimum durations or count thresholds to avoid noise).
- Rate-based: a single “operating” state with a throughput attribute (actual vs nominal rate), and microstops inferred from short, frequent transitions to non-operating states.
Choose one approach and implement it consistently. Changing approaches mid-stream without migration will break trendability and auditability of KPIs.
7. Handle manual interventions and overrides carefully
In regulated or high-mix environments, operator-initiated state changes and corrections are common. Model them so that:
- Manual changes are tagged as such (who, when, from which interface).
- Original machine-derived states are retained for traceability, not overwritten in-place.
- There is an audit trail capturing reason for the override, especially when it changes planned vs unplanned categorization.
This is important for ISO 22400 KPI credibility and for internal and customer audits. It also limits the risk that performance metrics are “massaged” without traceability.
8. Brownfield reality: normalize and reconcile across systems
In most plants, equipment state information is fragmented across:
- PLC/SCADA/IIoT signals
- MES operation states
- CMMS work orders and maintenance status
- Operator HMI / terminals / andon systems
For ISO 22400 KPIs you generally need an event consolidation layer (often in MES or a dedicated event store) that:
- Maps raw signals into the canonical state model.
- Reconcilers conflicting inputs using deterministic rules (e.g., safety trip overrides “operating” states).
- Resolves overlaps and fills gaps (with “unknown” state if necessary, not silent assumptions).
- Stores state history in a structure optimized for time-based queries and traceability.
Full replacement of legacy systems just to unify state modeling is rarely practical in regulated, long-lifecycle environments. A normalization and reconciliation layer lets you keep existing MES/SCADA/CMMS while still computing ISO 22400 KPIs consistently.
9. Validation, governance and change control
Because KPI outputs may influence maintenance, capacity planning, and in some cases customer reporting, treat the state model as a controlled asset:
- Document the canonical state definitions and mapping rules from each equipment/vendor.
- Version-control the state catalog and reason code hierarchies.
- Apply formal change control when altering state definitions or mappings.
- Validate KPI calculations when mappings change (e.g., before/after comparisons on representative lines).
Without this discipline, KPI trends can shift due to modeling changes rather than actual performance, which is hard to detect in long equipment lifecycles.
10. Typical failure modes to avoid
Common pitfalls when modeling equipment state events for ISO 22400 include:
- Multiple overlapping primary states per resource from different systems.
- Implicit assumptions about planned time when the production calendar is not integrated.
- No clear distinction between “operating” and “reduced speed” when performance KPIs are critical.
- Inconsistent mapping across assets or plants (e.g., the same OEM signal mapped differently).
- Loss of history when manual overrides overwrite raw data instead of appending corrections.
Detecting these issues early requires both data checks (e.g., no gaps/overlaps) and pragmatic line-walks with operators and maintenance to confirm that modeled states reflect real behavior.
Connecting to ISO 22400 KPIs
Once state events are modeled as above, ISO 22400 KPIs translate to time-based calculations on that state history. For example:
- Availability: time in operating states / planned production time.
- Performance: actual output vs theoretical output given time in operating states and nominal rates.
- Loss analysis: aggregation of unplanned downtime and reduced-speed durations by reason code.
The quality of these KPIs is only as good as the underlying event model and its alignment across equipment, lines, and plants.
