Modeling Manufacturing KPIs with ISO 22400: A Conceptual Data Guide

ISO 22400 offers more than a list of manufacturing KPIs. It defines how KPIs are conceptually built from time, states, and quantities so multiple plants and systems can describe performance in the same way. For architects and data engineers, that means you can design a KPI model that is structurally aligned with the standard even if each plant uses different technology and local metrics.

This article explains how the ISO 22400 KPI structure flows from raw machine data to derived indicators and, finally, to standardized KPIs. The focus is on conceptual modeling—how to think about data, relationships, and levels of aggregation—rather than on any particular database, historian, or analytics stack.

If you need a broader overview of the KPI families and use cases defined in the standard, see the hub article on ISO 22400 KPI definitions and concepts. Here, we go deeper into structure.

From Raw Data to Standardized KPIs in ISO 22400

ISO 22400 separates performance data into three abstraction levels:

• Raw signals from automation and execution systems
• Derived indicators that structure those signals into meaningful measures
• KPIs that aggregate indicators into standardized performance concepts

This layering is essential: it allows you to modernize data collection or change calculation logic while preserving standardized KPI semantics.

Raw signals: events, counters, and timestamps

At the base of the model are raw signals, captured by PLCs, SCADA, MES, machine controllers, or sensors. Typical examples include:

• Binary events (machine on/off, fault active, emergency stop)
• State transitions (RUN to STOP, STOP to IDLE)
• Counters (produced units, rejected units, cycles completed)
• Timestamps (shift start/end, order start/end, alarm start/end)

In conceptual terms, these signals are not yet indicators or KPIs. They are time-stamped facts about what the equipment or process is doing. ISO 22400 assumes that such signals exist and can be acquired, but it does not prescribe sampling rates, historian schemas, or telemetry protocols.

When designing a KPI model, these signals typically live in fact tables or time-series collections. Key attributes include:

• Equipment identity (work unit, line, cell)
• Context (production order, lot, product, shift)
• Event type (state change, count increment, configuration change)
• Timestamp (and, often, duration derived from consecutive events)

Derived indicators built from raw signals

Derived indicators turn raw signals into structured metrics that can be reused across many KPIs. ISO 22400 uses the term “indicator” broadly for measurable properties such as:

• Time in a specific state (e.g., minutes in RUN within a shift)
• Counts of produced, accepted, or rejected units
• Number of changeovers, alarms, or setup events
• Order-level durations (e.g., processing time, waiting time)

Conceptually, an indicator layer introduces:

• Aggregation rules (sum, count, minimum, maximum, etc.)
• Time windows (shift, day, order, batch, rolling horizon)
• Granularity (work unit, line, area, plant, order)

For instance, if raw signals show multiple RUN and STOP intervals for a machine during a shift, a derived indicator might summarize:

• Total RUN time for the shift
• Total STOP time categorized by reason
• Total produced good units and total scrap

ISO 22400 focuses on what such indicators mean and how they relate to KPIs, not on the low-level algorithms you use to calculate them.

Aggregated KPIs as standardized conceptual objects

At the highest level, ISO 22400 defines KPIs as standardized conceptual objects. A KPI in this sense is not just a number; it has defined attributes such as:

• Name and definition (e.g., equipment utilization as a relation between busy time and available time)
• Associated indicators and states (what times or quantities it uses)
• Time behavior (instantaneous, periodic, cumulative)
• Organizational scope (operator, supervisor, management)

From a modeling perspective, you can treat each KPI as a first-class entity that:

• References indicator definitions rather than raw fields directly
• Specifies how those indicators combine conceptually (for example, a ratio of two time categories)
• Can be calculated over multiple hierarchical levels (work unit, line, plant)

ISO 22400-2 enumerates a set of such KPIs but intentionally avoids prescribing detailed calculation formulas. The idea is that any implementation respecting the indicator relationships and time/quantity semantics can claim conceptual alignment.

Time-Based Foundations of ISO 22400 KPIs

Time is the primary axis for many manufacturing KPIs. ISO 22400 puts considerable emphasis on how time is categorized so that equipment-oriented and order-oriented metrics mean the same thing across systems.

Planned time vs. actual time

A foundational distinction in ISO 22400 is between planned time and actual time:

• Planned time: The time during which manufacturing resources are intended to be available for production (e.g., scheduled shift length).
• Actual time: The time during which manufacturing resources are actually in a particular state (e.g., running, stopped) within that planning window.

In a data model, planned time often appears in planning or calendar tables, linked to:

• Work centers and work units
• Shifts, crews, and calendars
• Production orders and schedules

Actual time is derived from events and state changes. Aligning these layers is crucial, because many ISO 22400 KPIs rely on comparing what should have happened with what did happen.

Busy, operating, and downtime categories

Within actual time, ISO 22400 introduces time categories that serve as building blocks for KPIs. While wording varies across sources, the following concepts are particularly important:

• Operating time: Time during which equipment is in a state that allows it to perform its intended function.
• Busy time: A subset of operating time during which equipment is actively executing work (e.g., producing parts).
• Downtime categories: Time during which equipment is not operating, further classified as planned (e.g., scheduled maintenance) or unplanned (e.g., breakdowns).

From a modeling perspective, you can think of these as:

• Mutually exclusive buckets into which every second of planned time is classified.
• Derived from equipment state and, optionally, reason codes.
• Summarized per time window and per object (equipment, line, order).

ISO 22400 then frames many KPIs as relationships among these categories—for example, comparing busy time to planned time or distinguishing impact of different downtime types. The standard does not mandate specific arithmetic formulas, but the structural relationships remain consistent.

Mapping time categories to performance concepts

The reason time categories matter is that they map directly onto high-level performance concepts such as:

• Availability: How much of the planned time the equipment was in states that could produce output.
• Utilization: How much of the available time was actually spent producing (busy vs. idle).
• Responsiveness: How quickly resources transition from non-productive to productive states after a trigger.

In a conceptual model, each KPI definition explicitly references the underlying time categories. That approach has several advantages:

• It keeps KPI meaning stable even if underlying event sources change.
• It supports consistent rollups across work units, lines, and plants.
• It allows different plants to implement slightly different calculation details while preserving the same conceptual building blocks.

Equipment States and Their Role in KPI Calculation

Time categories do not exist in isolation; they are derived from equipment states. ISO 22400 uses equipment states as the bridge between control-system events and KPI semantics.

RUN, STOP, IDLE, SLOW and other state concepts

While actual state taxonomies can vary by manufacturer or industry, ISO 22400 references typical concepts such as:

State	Conceptual meaning
RUN	Equipment is operating and producing as intended.
SLOW	Equipment is producing, but below target speed or capacity.
IDLE	Equipment is available and capable of running, but not currently producing.
STOP	Equipment is not operating; production is halted.

In a data model, these are typically encoded as:

• State codes in a dimension (RUN, STOP, IDLE, SLOW, SETUP, MAINTENANCE, etc.).
• State-transition events with timestamps, from which durations are derived.
• Optional reason codes that further classify STOP or IDLE periods.

The goal is not to enforce a universal state model, but to make sure that whatever state model you use can be mapped to ISO 22400 time categories.

How states map to standardized time buckets

Once equipment states are defined, they are mapped to the time categories described earlier. For example (illustrative only):

• RUN and SLOW might contribute to busy time.
• IDLE might contribute to operating but not busy time.
• STOP with a planned maintenance reason might contribute to planned downtime.
• STOP with a failure reason might contribute to unplanned downtime.

This mapping is where state granularity, business rules, and ISO 22400 concepts meet. For conceptual alignment:

• Ensure each equipment state is assigned to a single time category per context.
• Use reason codes to differentiate subcategories (such as changeover vs. failure).
• Maintain mapping logic centrally so all consuming systems use the same interpretation.

ISO 22400 does not prescribe your exact state list but assumes you can build such a mapping. This is often codified in reference tables or transformation layers in your data pipeline.

Consistency across automation and MES systems

Large manufacturers commonly operate heterogeneous environments: multiple MES solutions, different PLC vendors, and various historians. Without a common state and time-category mapping, KPIs like availability or utilization are not comparable across sites.

An ISO 22400-aligned model promotes consistency by:

• Defining a canonical set of time categories and KPI definitions.
• Maintaining plant-specific state-to-category mappings that respect local equipment differences.
• Applying those mappings prior to KPI calculation, so downstream analytics always see standardized concepts.

This approach keeps automation-layer diversity while still enabling cross-site KPI comparison and aggregation.

Quantity-Based Elements: Good Units, Scrap, and Rework

Besides time, ISO 22400 relies on quantities—what and how much was produced—to structure KPIs. These quantity measures interact with time categories to form throughput, quality, and efficiency indicators.

Material-related quantities in ISO 22400

Typical material-related concepts in an ISO 22400-aligned model include:

• Produced quantity: Total units or volume output in a period.
• Good quantity: Units that meet acceptance criteria.
• Scrap quantity: Units that must be discarded and cannot be reworked.
• Rework quantity: Units requiring additional operations before acceptance.

Indicators built from these raw counts may capture:

• Total good output for a production order.
• Scrap per product, per machine, or per operator.
• Rework volume linked to specific causes or inspections.

ISO 22400’s role is to define these concepts unambiguously so that, for example, “good quantity” has the same meaning in two plants even if they use different ERP or MES solutions.

Relating quantity measures to time categories

Many KPIs arise when you relate quantity to time. A conceptual data model should encourage explicit relationships between:

• Good units and the busy time during which they were produced.
• Scrap quantities and the time in states associated with the scrap (e.g., during ramp-up, changeover, or specific equipment configurations).
• Rework quantities and additional processing time required.

Structurally, this often means:

• Capturing quantities in fact tables keyed by order, product, and work unit.
• Linking those facts to time windows defined by equipment states or order milestones.
• Allowing KPI definitions to reference both time and quantity indicators together.

ISO 22400-inspired KPIs such as order execution reliability or production efficiency then become well-defined combinations of time and quantity elements, not ad-hoc calculations.

Conceptual links to quality and throughput KPIs

By standardizing the meaning of good, scrap, and rework quantities, ISO 22400 supports families of KPIs that address:

• Quality performance (e.g., proportion of accepted units within a time period or order).
• Throughput (e.g., output volume per time category, line, or order).
• Resource effectiveness (e.g., how much good product is produced per unit of equipment time).

Again, the standard frames these relationships conceptually; organizations remain free to choose the specific thresholds, targets, and improvement practices that fit their context.

Designing a Data Model Aligned with ISO 22400

Putting the pieces together, a standards-aligned KPI environment is primarily a conceptual modeling exercise. The goal is to represent indicators and KPIs—and their relationships—in a way that mirrors ISO 22400’s abstraction levels.

Representing indicators, KPIs, and relationships

A typical conceptual structure may include:

• Event/Signal entities for raw data (state changes, counts, alarms).
• Time-category indicators derived from events (operating time, busy time, downtime categories).
• Quantity indicators (produced, good, scrap, rework quantities).
• KPI definitions that reference indicator types and describe relationships.

In many implementations, KPI definitions are stored as metadata, for example:

• An identifier and name (aligned with ISO 22400 terminology where applicable).
• References to the indicators they depend on.
• Attributes such as direction of improvement, unit of measure, and primary audience (operator, supervisor, manager).

This makes KPI behavior transparent and supports change management. When you adjust an indicator or mapping rule, you can see which KPIs are affected.

Dealing with multiple levels: work unit to plant

ISO 22400 aligns with enterprise-control hierarchies such as those defined in IEC 62264, including levels like work unit, line, area, and plant. A KPI model should therefore:

• Associate events and indicators with the lowest relevant level (often the work unit).
• Support rollups along defined hierarchies (work unit → line → area → plant).
• Allow KPI definitions to be evaluated at multiple levels using the same semantics.

In practice, that often means maintaining dimension tables for equipment, areas, and sites, plus bridge tables for temporary groupings (such as production cells reconfigured for a particular campaign). KPI calculations then use group-by operations or hierarchical aggregations to move between levels without redefining KPI meaning.

Supporting future extensions without breaking the model

Because ISO 22400 defines a core set of KPIs but does not cover every possible industry- or plant-specific metric, your model should anticipate extensions:

• Keep indicator and KPI definitions data-driven so you can add new ones without schema changes.
• Clearly distinguish KPIs that are ISO 22400-aligned from those that are local or experimental.
• Preserve the separation between conceptual definitions and implementation details (e.g., calculation code, materialized views).

This approach lets you expand your KPI portfolio—for example, adding aerospace- or MRO-specific indicators—while continuing to rely on ISO 22400 as the backbone for cross-site comparability.

Using an ISO 22400-Aligned Model in Connected Environments

Modern plants operate with interconnected ERP, MES, SCADA, historians, and analytics platforms. ISO 22400 provides a common language that these systems can use when exchanging performance information.

Interfacing with ERP, MES, SCADA, and historians

In a connected architecture, different systems contribute different pieces of the KPI puzzle:

• SCADA and control systems provide state transitions, counts, and alarms.
• Historians store high-frequency time-series data.
• MES offers order context, routing, and execution events.
• ERP carries order planning, product definitions, and financial context.

An ISO 22400-aligned data model sits above these systems and:

• Normalizes events into standardized equipment states and time categories.
• Relates order and product information to time and quantity indicators.
• Calculates KPIs using definitions that are independent of any one system’s internal schema.

This reduces the need for custom metric translation each time you connect a new plant or vendor system.

How platforms like {{hub}} consume and expose KPI structures

A platform that implements ISO 22400 concepts—such as {{hub}}—typically uses the standard in three ways:

• Ingestion: Map incoming signals, events, and order data into ISO 22400-aligned indicators (state-based times, quantities, order-level durations).
• Modeling: Maintain KPI definitions as metadata that explicitly reference these indicators and the relevant time behavior.
• Exposure: Provide dashboards, APIs, and reports where KPIs retain their ISO 22400 names and attributes so that downstream consumers know exactly what each value means.

Because the conceptual layer is standard-based, {{hub}} can integrate multiple plants and suppliers while preserving KPI meaning. At the same time, it can host additional domain-specific indicators as long as they are clearly identified as non-standard.

Maintaining conceptual purity when adding custom KPIs

In practice, most organizations need KPIs beyond those explicitly listed in ISO 22400—especially in specialized domains such as aerospace or MRO. You can extend your model while remaining conceptually faithful to the standard by:

• Reusing ISO 22400 building blocks (time categories, quantity definitions, equipment states) in new KPIs.
• Labeling custom KPIs as such, separate from ISO 22400-aligned ones.
• Documenting any additional assumptions (for example, regulatory constraints or customer-specific quality rules).

This way, you preserve comparability for standard KPIs while still supporting the local metrics required for your specific business and regulatory environment.

Bringing It All Together

ISO 22400’s value for architects and data engineers lies in its structural view of KPIs. It provides a vocabulary and a set of relationships that connect raw signals, time and quantity indicators, equipment states, and standardized KPI concepts. By mirroring this structure in your data model, you enable:

• Consistent KPI semantics across heterogeneous systems and plants.
• Clear separation of concerns between data acquisition, indicator calculation, and KPI definition.
• Safe extensibility with custom KPIs that do not undermine standard-based comparability.

The standard deliberately stops short of prescribing formulas, database schemas, or improvement strategies. Its role is to ensure that when you talk about utilization, availability, or order execution performance, everyone involved shares the same conceptual understanding. The implementation details—technology stack, algorithms, and visualization—remain yours to choose.

For a fuller overview of KPI categories, domains, and use cases across production, maintenance, and quality, refer back to the hub on ISO 22400 manufacturing KPIs. Once the structural foundations are in place, those standardized KPI definitions become far easier to implement and trust across your operations landscape.